rust-fnv VS getopt

Use faster hashing function (e.g. fnv, there are other potentially faster options as well). By default Rust std uses a DoS-resistant function, which is relatively slow.

Looking at ripgrep myself, I'm seeing some trivial dependencies. One is fnv. Perhaps you're not aware, but FNV-1a is literally ~4 lines of code. It's about as sophisticated as left-pad. I've written it from scratch a dozen times off the top of my head (the official offset basis and prime are really not special, so you can just generate your own). It would take you about a minute to eliminate it.

Between -std=c99 and removing these headers, you're missing time definitions (struct timeval, gettimeofday) and option parsing definitions (struct option, getopt_long). Mingw-w64 provides all this for compatibility, but MSVC has none of these, so you'll need to write replacements. I've written embeddable, public domain implementations of getopt and something like getopt_long, in case that helps. These are how I deal with option parsing portability.

The option parser is crude and doesn't follow conventions. Particularly the lack of -- support (disables option parsing) would make it impossible to use safely in scripts. If you don't want to use the system or toolchain-provided getopt, here's a public domain, embeddable implementation: getopt.h

On unix-like systems there's a getopt function for parsing short options. Mingw-w64 has one as well, to cover Windows programs. If I care about portability, I just embed my own so it not only works everywhere, it behave the same everywhere, too.

https://github.com/skeeto/getopt/blob/master/getopt.h (short)

Not only the GNU, you have an example in this thread where someone suggested to use or roll something similar to https://github.com/skeeto/getopt/blob/master/getopt.h, which, surprise, depends on strchr, a function that solves a much trivial problem than POSIX getopt, to begin with.