Ref:
https://github.com/varnishcache/varnish-cache/commit/681c11998ec56dc4460a30585210f95a7850ea3b

Only call strcmp() once, when a node is reached that must be either a
hit or a miss.

The search may have matched a string that is actually a prefix of
the subject string, if a longer string with the same prefix is also
in the set.

This "happens" to give correct results for match(), but which()
would return the wrong value.

The fix uses strcmp() instead of memcmp(), but that is also
vectorized, where the C library uses vector instructions.

Vector extensions are common hardware now, as are C libraries that
use vector instructions to implement functions like memcmp(). So
we hand off compares to the lib to get the advantage.

For the same reason, we can afford to call strlen() on the subject
string to locate the terminating null, rather than scan for it.

Also, the match function descends through the trie to find a
potential match, and does the comparison only then, as is common
for trie/critbit/patricia implementations.

since varnish-cache ecef48518f3b3f4bbf28256e090bdbb5cd2b163c backends
can be NULL (as defined with backend <name> None)

Fixes #1

configure checks if you have lcov & genhtml; these can be specified
with --with-lcov and/or --with-genhtml.

If they are available, then make coverage does the following:

- make clean, then make check with CC=gcc and CFLAGS set so that
  inputs for gcov/lcov are generated.

- lcov creates the src/coverage subdir and generates a targetfile
  there.

- genhtml generates HTML reports in src/coverage.

See also https://github.com/varnishcache/varnish-cache/issues/2967
for a general discussion regarding an inconsistency in the WS_Reserve()
interface