This makes the code easier to reason about, as it will behave the same
way regardless of whether there is any more data coming after the
presumed end of the prologue.
FWIW, in my case, I just use my emails as my review queue, so I don't mind others approving too.
I wonder if it's worth a comment at the start here saying something to explain why the formatting of the following bytes is weird. Perhaps something like "The following bytes would be read as part of the prologue header, were data extraction not stopped once the data end is reached, hence they are formatted like a header".
Something similar applies for the other changes in this file.
I think this comment is missing a word somewhere. Probably "truncated"? Also missing a trailing full stop. Also "md5" -> "MD5".
This should probably show that the last opcode within range is read successfully in addition to showing the past-the-end one is recorded as zero.
Missing trailing full stop.
This may not have been clear from the test comments before, but this and the previous case were supposed to work in tandem, because the invalid MD5 form message was reported in both cases, but not the "not at end" message IIRC.
I feel like the input for this case probably should be updated to not have a malformed MD5 form. Is there any interaction any more to do with continuing to parse that these 2 cases now don't need to cover?
How straightforward would it be to provide the offset as extra context here, like we do with "unexpected end of data"?
I'm not sure where this error is coming from (I don't recall seeing it before), but it's got a spurious trailing full stop, which is inconsistent with the other error messages. It might want fixing separately I guess.
What happened to this error message?