src: fix StringSearch compiler warning

[sam-github]

StringSearchBase has tables (int array members) that are used only for
some search strategies, but g++-9 (at least) doesn't understand when
they will or will not be used. Default-initialize them in the
constructor to avoid this warning:

In file included from ../../src/node_buffer.cc:29:
../../src/string_search.h: In function ‘size_t node::stringsearch::SearchString(node::stringsearch::Vector<const Char>, node::stringsearch::Vector<const Char>, size_t) [with Char = short unsigned int]’:
../../src/string_search.h:113:30: warning: ‘search’ may be used uninitialized in this function [-Wmaybe-uninitialized]
	113 |     return (this->*strategy_)(subject, index);
			|            ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
../../src/string_search.h: In function ‘size_t node::stringsearch::SearchString(node::stringsearch::Vector<const Char>, node::stringsearch::Vector<const Char>, size_t) [with Char = unsigned char]’:
../../src/string_search.h:113:30: warning: ‘search’ may be used uninitialized in this function [-Wmaybe-uninitialized]
	113 |     return (this->*strategy_)(subject, index);
			|            ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~

Checklist

• commit message follows commit guidelines

[sam-github]

I believe the default initialization is a no-op, so no value will be written to memory, so that there is no performance impact. If that's not correct, some other strategy might be needed (if search construction is in critical path).

[addaleax]

I believe the default initialization is a no-op, so no value will be written to memory, so that there is no performance impact.

It’s not – this will lead to zero-initialization: https://godbolt.org/z/2TcRgT

[lundibundi]

The search_string ones are caused by uninitialized arrays (they are initialized when needed and not upon object creation) in SearchStringBase which can be initialized (i.e. = {0}) with 1-2% performance impact or suppressed with something like #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" (this should also work for clang). Not sure if this is needed though pragma ignore would probably be fine.

From #26733 (comment).

There is also #31532.

[bnoordhuis]

Alternative solution: #31809