Known to fail on VMs (such as the buildbots), see eg
http://blog.badtrace.com/post/rdtsc-x86-instruction-to-detect-vms/

This is particularly problematic when calling FD_SET( -1, ... ), but let's
check it in all functions.

This was introduced with the new API and the fact the net_free() now sets the
internal fd to -1 in order to mark it as closed: now using this information.

Now centralized in the platform layer

The "inline" keyword is supported since Visual Studio 2005 according to MSDN,
and we require Visual Studio 2010 or higher.

We now require support for stdint.h from the compiler.

Too recent (about one year).

Print only the basename from the file, and print level too.

For some reason select() doesn't seem to work.

This is made possible by the new API where net_accept() gets a pointer to
bind_ctx, so it can update it.

close() may be more meaningful, but free() is symmetric with _init(), and more
consistent with all other modules

Provides more flexibility for future changes/extensions.

On Windows, recvfrom() returns an error code if the destination buffer is too
small to hold the next datagram.

But introduces dependency on variadic macros

Assume we have two trusted CAs with the same name, the first uses ECDSA 256
bits, the second RSA 2048; cert is signed by the second. If we do the keysize
check before we checked the key types match, we'll raise the badkey flags when
checking the EC-256 CA and it will remain up even when we finally find the
correct CA. So, move the check for the key size after signature verification,
which implicitly checks the key type.

When we build with Visual Studio in debug mode, the invalid parameter handler
aborts the application (and offers to debug it) when n is 0. We want to
just return -1 instead (as calls with n == 0 are expected and happen in our
tests).

For the sake of systems where we want gmake.

Used to fail on our FreeBSD and Windows buildbots. Seems to be working at
least on my Darwin physical machine and on my Windows VM with MSYS2 now.

Some versions of "which" print on stderr.

x509_get_name() does not make defensive copies of strings in its input (which
is OK as usually the caller will have made a copy already), so we shouldn't
reuse its input buffer as an output while "parsed" is still alive.

Our Windows implementation based on vsnprintf_s( ..., _TRUNCATE ) sometimes
writes *two* terminating NULLs. Allow for that, but obviously bytes past the
end of the buffer mustn't be touched.

Name chosen to match the existing make target.

I was a bit too trigger-happy with copy-pasting in a previous commit...