As mentioned in this thread
https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/263934/ for $hfind (but it's the same now for $bfind().regex), doing a regex search on a binvar will make $regml() and $regmlex() truncate results at the maximum length.
This makes it tricky to manipulate the binary variable, especially since mIRC does not provide a way to access the full match, only captured group.
In such case, often, $regml/$regmlex().bytepos of one or more captured group is used to extract data, via bcopy.
To calculate an appropriate byte position in the binary variable, you'll need the length of the capture group, where the length in this case will be incorrect.
In this case, the accurate length cannot be obtained without modifying the regex pattern, for example, adding an empty capturing group right after the capturing group you are dealing with, and getting the difference in position, the problem is that depending on the pattern, it could easily break, and having to tweak regex pattern to solve that is an issue.
Having a new $regml/$regmlex().len and .bytelen property reflecting the length of the captured group would be helpful in this case.
And yeah, if mIRC could get Full match support in regex via $regmlex(N,-1) (difficult to implement with $regml with multiple match so just in $regmlex()) it would be awesome.
Example (fail on large capture):
;extract the captured group and overwrite the binvar with only that
noop $bfind(&a,0,/part1(.*?)(?=part2)/s,n).regex
bcopy -c &a 1 &a $regml(n,1).bytepos $calc($regml(n,1).bytepos + $len($regml(n,1)))
Quick fix that would fail if pattern is using backreference itself
;add empty group to get position
noop $bfind(&a,0,/part1(.*?)()(?=part2)/s,n).regex
bcopy -c &a 1 &a $regml(n,1).bytepos $calc($regml(n,2).bytepos - $regml(n,1).bytepos)
Suggestion:
noop $bfind(&a,0,/part1(.*?)(?=part2)/s,n).regex
bcopy -c &a 1 &a $regml(n,1).bytepos $calc($regml(n,1).bytepos + $regml(n,1).bytelen)
I understand that $regml/$regmlex() can take a binvar parameter which would extract the content correctly already, however this is just an illustration, you may need the position without needing to extract to a binvar, and well, extracting to a binvar would be costly in this case, rather than storing a position.
