Re: msys inet_pton strangeness

Just an idea...

--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -16,7 +16,7 @@
* get support for GetLocaleInfoEx() with locales. For everything else
* the minimum version is Windows XP (0x0501).
*/
-#if defined(_MSC_VER) && _MSC_VER >= 1900
+#if !defined(_MSC_VER) || _MSC_VER >= 1900
#define MIN_WINNT 0x0600
#else
#define MIN_WINNT 0x0501

That was done to reveal the Vista locale stuff, which MingGW certainly
has: we're calling it unconditionally in the master branch in at least
one place (and we should do more of that, to make MSVC and MinGW code
paths the same wherever possible). In 15 the users of
GetLocaleInfoEx() are guarded with checks that you're on MSVC so it
still wouldn't actually call them anyway.

Obviously it's not good to change the target in the back branches.
But apparently it already changed by accident due to some header order
nonsense (could it be related to MinGW's recent switch to the UCRT by
default?), so changing it again so that it compiles seems OK? We
don't seem to have a documented MinGW support range, and I've always
sort of assumed that it's just 'recent versions only' because it's
effectively only for developers (cross builds and suchlike). And it
certainly didn't really intend to be runnable on Windows XP
(PostgreSQL 11 was the last to claim to run on Windows XP (0x0501)).
I doubt anyone's actually going to test this on Vista or other ancient
SDKs either, which is why I was looking for a change that *only*
affects MinGW and doesn't risk changining anything for MSVC users on
the retro-computers and toolchains we claim to support. For example,
header order dependencies and side effects are a little chaotic on
that OS, so you could easily break something else...

I guess the objection would be that (apparently) some translation
units are being compiled with 0x0603 from system headers, and this one
would use 0x0600, which might be confusing.