![]() ![]() It's also open source, no confusing and ambiguous bytecode to run. It is not clear that there are no other restrictions, so we have to keep on looking.Įverything is documented on the pcre site. ![]() One restriction for the search string (no "\E" inside) Similar workarounds for setting the length of a binary Needle surrounded by \Q.\Eģ. ![]() Workarounds for passing binary HayStack to RegExMatch with the proper length informationĢ. Raw buffer searching and regex have their trade-offs and either are suited for different applications.I don't want to suppress alternatives, but they have to work, or at least their limitations should be documented. I never expected that you would be so adamant to suppress alternatives techniques. A "\E" might not cause errors, but faulty results. It has nothing to do with "if your program is so poorly designed without fault tolerance and control": but working correctly with all possible input. The resulting function should work with any combination of these special cases, which could make it long, complicated and "ugly". If you have a function, which accepts a binary search string S, in where you have to replace each "\E" with something like "\E\E\Q", you face serious difficulties coding in AHK, because S might contain \0's, RegEx control sequences, AHK escape sequences, %.% look-like references, etc. 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.It is not about replacing a single \E, but possibly many of them. This is often a cause of bugs and security holes which AutoHotkey's uniquely simplistic syntax aims to prevent in the first place. \Q.\E does not helpThat is only true if your program is so poorly designed without fault tolerance and control. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |