You misunderstood, I used \x61 as a control in the benchmark test so you could easily replace it with any other hex value to observe an identical result. In the previous script I had written expressions that used '\d' and '.' to a similar effect, any valid regex pattern can be used. Again, it doesn't hurt to try yourself before coming to such presumptions.Your example indicates that in the search string we have to replace each special character ([]()"\'.*?<>^$|null…) with a hex (or octal, as in your example) escape sequence (or precede them with ""), which is not a very elegant solution.

Machine code binary buffer searching regardless of NULL

autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit


I don't mean to depreciate your work, it's certainly most impressive to see assembly used in AutoHotkey. I just find that regex can satisfy most requirements, including searching for and past null characters.

autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit
Your example indicates that in the search string we have to replace each special character ([]()"\'.*?<>^$|null…) with a hex (or octal, as in your example) escape sequence (or precede them with ""), which is not a very elegant solution.
I did try myself. I was speaking about the scenario where you search for a binary pattern, like a piece of code in a program, or an embedded MD5 signature, or descriptors of images, videos. These patterns are normally taken from other files. You cannot use those patterns directly as the search string, can you? You have to "replace each special character", convert the non-printables to escape sentences, that is, first you have to process the search string. If I misunderstood, and you can use a binary file or buffer directly as the search string in another buffer, please tell the trick. I tried the following:You misunderstood, I used \x61 as a control in the benchmark test so you could easily replace it with any other hex value to observe an identical result. In the previous script I had written expressions that used '\d' and '.' to a similar effect, any valid regex pattern can be used. Again, it doesn't hurt to try yourself before coming to such presumptions.
FileRead a, *c %A_AhkPath% VarSetCapacity(b,StrLen(a),1) DllCall("RtlMoveMemory", UInt,&b, UInt,&a, Uint,StrLen(a)) VarSetCapacity(y,4) Loop % StrLen(a) { x := NumGet(b,A_Index) NumPut(x,y) r := RegExMatch(b, y) If ErrorLevel <> 0 MsgBox %A_Index% : %ErrorLevel% }I got the following msg:
---------------------------
test.ahk
---------------------------
1006 : Compile error 14 at offset 4: missing )
---------------------------
OK
---------------------------
It shows that some 4-byte binary search strings lead to errors.

L:=binNeedleLength VarSetCapacity( binNeedleSpoof, L+4+1, 0 ) binNeedleSpoof=\Q binNeedleSpoof2=\E DllCall("RtlMoveMemory", "uint",&binNeedleSpoof+L+2, "str", binNeedleSpoof2, "uint",2) DllCall("RtlMoveMemory", "uint",&binNeedleSpoof+2, "uint", &binNeedle, "uint",L) res:=RegExMatch( buf, binNeedleSpoof)
hmm looks pretty terrrrrifying :-D

varsetcapacity( hay, 100, 0 ) hay=aaa varsetcapacity( n, 10, 0 ) msgbox % "hay: " hay ". pos=" regExMatch( hay, "\Q" . n . "\E" )

RtlMoveMemory or something to update the StrLen value is probably needed in your script due to AutoHotkey's limitations with binary variables.

autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit

You should know that \Q...\E does not help. The binary search string could contain "\E", which is still interpreted as a control sequence. There could be other forbidden substrings, too.Try with \Q\E... and before you ask it's in the manual.
y = \E)) ; binary string containing "\E" r := RegExMatch(b, "\Q" . y . "\E") MsgBox Error = %ErrorLevel%
If the search string contains \0, other tricks are needed in AHK (as I noted earlier): VarSetCapacity and dllcall to RtlMoveMemory or NumPuts to have the desired StrLen. You can make a wrapper function, but it is still ugly.

That is only true if your program is so poorly designed without fault tolerance and control. This is often a cause of bugs and security holes which AutoHotkey's uniquely simplistic syntax aims to prevent in the first place. It's ironic how you find the need to replace a single \E so mundane and 'ugly' knowing the overheads of a machine code function.\Q...\E does not help
I never expected that you would be so adamant to suppress alternatives techniques. Raw buffer searching and regex have their trade-offs and either are suited for different applications.

autohotkey.com/net Site Manager
Contact me by email (polyethene at autohotkey.net) or message tidbit