This just removes the layer between `prepare_pattern` and
`prepare_pattern_raw`; the function now always returns the
allocated vector.
Oddly, it wasn't possible to encode this using an Option<> in the
`hunt()` function. The `usize` of the scan variable meant that we'd
never go below zero legally (and Rust wouldn't let that happen), so
the "if we're at zero we have some special cases to check" had to
remain here. The C version of this code could say "If this pointer
is below the allocated space" which is, to a Rust developer, hella
weird (you're literally pointed at memory you don't own!).
And despite the allocation, despite the special case checks, this code
is *still* twice as fast as its C implementation.
The C and Rust versions are now comparable, with a memory-reuse and
a memory-safe version for Rust. The memory-safe version is five times
faster than the C version; the memory-reuse version (technically safe,
but can panic under some very rare circumstances) is ten times faster.
I suspect the reasons for he speedup are strictly in the `for()` loop
in the C version for copying the string, where the Rust version probably
uses memcpy() under the covers to transfer the short string into the
destination.
Added the squozen patprep function, added unit tests to the
patprep `c` code, and ensured that the rust version works the
same way. The only remaining code slowdown is that re-allocating
the Vec 50 million times turns out to be slower than re-using the
same slice of RAM over and over and over.
Elf M. Sternberg