bobusumisu / go-ahocorasick Goto Github PK

Stack overflow in computeFailLink when adding a pattern with consecutive zeroes.

Great library, thanks. The following 2 wishes would be easy to implement (and I'll probably do it for my own purposes in a private copy), but they might also be useful in the whole project. The background is an application like an Antivirus scanner or Yara that should avoid detecting itself or being detected as malware by another AV by mistake. So the actual search patterns should not appear directly in the application (this is not a cryprographic need as with passwords, but less strict, a false-detection-prevention). A trie is a perfect construct to avoid these false positives - but as you need to build the trie first, the actual byte patters appear at this stage in memory, and Go makes it hard to really wipe them afterwards because of GC. The easiest way would be to use pre-compiled tries, so the trie building happens in a seperate program once, and just a byte representation of the trie is used by the final application. To do this, a simple marshaling and unmarshaling of the Trie struct suffices, but as the fields are private, it can't be done from outside the library, AFAIK (maybe through reflection, but better not think about it... I think even this can only read, and not write private fields).

The second problem occurs if you have several match patterns; currently, you still need to finally compare the found matches with the actual patterns. To avoid this, it should be possible to give (or get) an additional integer identifier when adding patterns, which is also returned in the actual Matches structure, so the final app needs only compare those. The final app of course must know what of these IDs map to which patterns, but can do so without containing the actual patterns in its code. Note: the fact that in case of an actual match, an additional detection by another AV actually is not an issue, because it would then of course not be a false positive anymore :-)