itoa VS optparse

The hyper package for the crab language actually has a dependency on a package that does itoa (among others) so IMO the problem exist there too and most non trivial packages will be bloated

I see itoa which seems trivial on the surface. The implementation is highly optimized, but it's also covering all the different cases. I'm guessing this is for printing match counts or line numbers, and if this is actually a bottleneck for ripgrep — which seems unlikely — then maybe it's worth it. You know your own needs, and if it was a bottleneck, I bet you could do just as well, if not better, with a custom, smaller, simpler solution inside ripgrep. (i.e. just make sure the power-of-ten denominators are available at compile time so the compiler won't generate divisions.)

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.

getopt_long is a GNU extension, common across unix-like systems, for parsing long options. You can find libraries for functionality as well.

When I need something more sophisticated, where long options would be nice, I reach for my own Optparse.

https://github.com/skeeto/optparse (short and long)

This is bug-free and feature complete so it never needs to be updated. When I need argument parsing in a C program, I just copy-paste that into my source and massage it into place. Sometimes I cut the fprintf() stuff, or replace the isalnum, or otherwise adapt it to fit the program's needs. The point is that it becomes wholly owned by the project using it. It's a similar story for long option parsing.