I actually meant something else.

That specific bug is only going to bite if you had a search string that was the whole line and also was the last line in a file without a return. Similarly if $/ is set to a multi-line delimiter (eg \r\n because you are reading a DOS file in Linux) and the string you are looking for happens to include a tab right where a shorter entry has the \r, you may wind up with an incorrect location. (\r comes after \t, but no character should come before \t.)

But look more carefully, there is another bug lurking in that code aside from the use of chop where chomp is a better fit.