Ok, since I also had some problems with false results returned by $bfind, I was playing around to find a way to make my script work...
I'm still not completely sure what causes the bug to happen, but I'm pretty sure it has something to do with "/bcopy -c".
The bug only seems to be reproducable when you've done a /bcopy -c on the binvar which decreases it's length.
So here's my theory:
/bcopy [-zc] <&binvar> <N> <&binvar> <S> <M>
This copies M bytes from position S in the second &binvar to the first &binvar at position N. This can also be used to copy overlapping parts of a &binvar to itself.
If you specify the -c switch, the first &binvar is chopped to length N + M.
The above quote is from the mirc help. It says the binvar gets chopped to length N + M, which doesn't make much sense. If you think about it, you will come to the conclusing that the binvar should be chopped to the lenght N + M - 1, because the first position in a binvar is not 0, but 1.
So I guess there's no bug in $bfind, but a logical misconception in the way /bcopy -c works. Using /bcopy -c on a binvar will return a binvar which is one byte longer than expected (if it gets chopped that is). That would explain why $bfind finds the whole match when reaching the "end" of a binvar, which isn't really the end.
Sorry for my bad english, I hope my explanations made sense
