Sounds exciting! I like your approach, and I agree with your basic theory. 
Thanks for sharing the details.

> git and an ssh client fairly soon

As part of dogfooding and testing w64devkit, I've set up a development 
environment from scratch in a fresh install many times. The "Portable Git" 
distribution — a self-extracting 7zip archive — has been far superior to 
the standard installer. The installer tries to be "friendly" by asking 
lots of annoying questions that simply don't need to be asked, with more 
questions added from time to time. The portable distribution doesn't need 
any of this information, so obviously it's inessential. Like w64devkit, 
"uninstall" is just a matter of deleting one directory and leaves behind 
no mess.

> tutoring a windows user in programming! (while, admittedly, trying to 
> expose them to the unix-style toolchain via w64devkit)

This sounds interesting! I'm curious about your approach and ideas if 
you'd like to elaborate.

In case you hadn't seen this yet, by coincidence I just happened to 
stumble across this today:

static cross- and native- musl-based toolchains
http://musl.cc/

I only just recently learned about --with-pic while fixing gfortran for 
w64devkit, and so far it's worked fine there with only static libraries. 
GCC's libquadmath wasn't being built as PIC, while the latest Binutils is 
PIE-only on Windows, making it unlinkable. So, sorry, I don't have any 
specific insights there.

A useful way to approach this is treat it as cross-compilation. Try 
intentionally targeting a different architecture with your build script to 
avoid accidentally picking things up from the build host. Perhaps your 
host's libstdc++ is getting in the way.

You have a interesting idea, Harris. Static musl is definitely the way to 
go in the long run, and I can imagine some uses for this. I've gone 
partially down this route myself in a few different ways, but not to the

The cycle-walking of the Kensler permutation does not require a full 
period, so that's probably why you couldn't find this information. :-) In 
fact, the permutations it's typically built on, including mine, have lots 
of independent cycles, and even fixed points.

How could this possibly work? It's subtle, and it's tripped me up every 
time I revisit it: The starting index is guaranteed to be in range since 
the caller must only ask for an index in range. Before considering this 
index, it's permuted, potentially going out of range. Eventually this 
cycle-walk must come back into range since it started in range with the 
original index.

The primary "hash prospector" tool described in my article, with the x86 
JIT compiler, will practically never find anything nearly as good as 
functions listed in the README. Its search is too random. The main result 
was steering me towards multiply-xorshift hashes, essentially re-inventing 
the concept. Run it long enough and it eventually discovers this pattern, 
never reporting anything else thereafter.

All my good results come from my "hillclimb" tool which explores and 
refines the multiply-xorshift parameter space. Notably it doesn't JIT, and 
so I can run it on a Raspberry Pis and such. Just pipe it into tee inside 
a tmux session, and check on it a week later.

I've run "hillclimb" for months on end on various spare computers, 
including a couple of Raspberry Pis. It probably amounts to a decade of

Interesting topic, Harris!

> (I gather this is a mingw/gcc issue)

Yup, it's not (yet?) implemented by Mingw-w64. Though, there's little 
point to doing so anyway. C11 threads have completely failed to achieve 
their one purpose: a portable thread interface across implementations that 
support threads. This is mostly Microsoft's fault as the main holdout. For 
decades we've had pthreads as a standard, mature, portable threading API 
available everywhere threads are available… except MSVC where you have to 
use Microsoft's proprietary thread APIs.

C11 threads were meant to address this sort of thing, but Microsoft isn't 
interested in implementing that API either. Anywhere you might find C11

Interesting, and thanks for the heads up, Marc! I didn't know about 
mimalloc using lowbias32. In case you hadn't noticed, I've since found 
some very slightly better 32-bit mixers. I haven't given them fancy names, 
and the statistical difference is so small that it probably makes no 
difference in practice, but they're available for use (under "more 2-round 
constants"):

https://github.com/skeeto/hash-prospector#two-round-functions

Even better, the second best I've found, which itself is also better than 
lowbias32, has an efficient inverse.

> Unfortunately, I didn't find a reverse, so I wrote one myself

I don't think you understood my article since I agree with you about such 
pleas and professional competence. I'm not talking about safety beyond 
simple correctness. Anywhere you might use strcpy() (or strlcpy(), etc.) 
it makes more sense to use memcpy(). If you can't drop memcpy() in its 
place then you're not using strcpy() correctly. I've never seen a 
legitimate use case for strcpy() (or strlcpy(), etc.), and I'm speaking 
strictly from a perspective of correctness and efficiency — qualities I 
believe are more important than safety.

The point of the article is that anywhere you might use strlcpy() you 
should instead use memcpy() anyway. There are no advantages to using 
strlcpy() even if it is available.