One of the test strings in runner.mips is the empty string, which should be refused as invalid. This test works correctly.
However, in scan after running the test, the runner accidentally skips past the next test by adding to the address before checking if the byte is null already (in the manner of a do…while loop). It should instead check if the byte is null at the top, and only proceed if it’s not (in the manner of a while loop).
The consequence of this bug is that the test runner skips the “134456729” test string directly after “” and instead reads one past the ins array. It quickly finds an invalid test string there in the first word so everything seems to be going correctly.
I came here from creating a PR fixing the issue, evidently not having noticed the contribution policy requires a forum thread, so a PR already exists to fix the issue. The fix is, however, trivial, and could be reimplemented in a matter of minutes if that’s preferrable to merging the PR.
As an extra detail: I found this issue by trying to add additional test cases to my local copy of the test runner to test some additional cases, and finding out that adding a new test string and a new expected test result didn’t actually seem to work correctly (adding a valid string to the end and giving it an expected value of 1 would end up with a result of “expected 1 to be 0”).
After being perplexed about this for a while, I noticed that it was happening only after the empty string, and tracked the issue down to scan behaving as described above.