There is no way to do this. The library is behaving as it should "HS_SUCCESS and no callback" just means you've scanned and not found anything. It's not an error to wind up in a state where you can't find matches.

Historically, the closed-source Hyperscan had this functionality, but the open source Hyperscan doesn't.

We didn't remove this functionality gratuitously. There are a lot of optimizations in Hyperscan that involve being a little 'lazy' - even in streaming mode. We keep a short window of the old input around (in addition to other, more principled streaming state like DFA and NFA state) so if we can establish that we aren't going to raise a match on a first stream write and are given a short write, it's permissible to defer the stream write until we have more data (which improves performance on short writes).

As a result, having an accurate "is_exhausted" call meant doing our optimizations differently - resulting in an entirely new mode of doing things. Add in a few modes like that and you've drastically increased your testing surface and complexity.

Note that the library may well optimize this case - it can recognize that you're in the 'exhausted' state and that there's no work to do, and go really fast; there's just no API method to get at the internal state and the internal state is an optimization only. As such there's a lot more flexibility to handle this without baking it into an API.

Geoff.

On Wed, Mar 20, 2019 at 3:30 AM Eric Rongo <ericr@extrahop.com> wrote:
Hello,

I've recently run into the following issue:

Suppose the match pattern is "^abcdef" and I'm using streaming mode.

If I call hs_scan_stream with "abc", I get HS_SUCCESS but no callback.  This is what I expect.

However, if I call with "xyz", I still get HS_SUCCESS with no callback.  This is a little confusing because I would expect it to (somehow) tell me that I haven't matched and never will.

Is there any way to know that I can't possibly match?  If not through a return code then maybe by peeking at some internal state?

That is, is there a way to differentiate between no match and no match *yet*?

Thanks for your help.

--
ERIC RONGO
Sr. Software Engineer | Platform & Framework

ericr@extrahop.com