fix callconv warning

[Mistuke]

_WIN32 is always defined on a Windows compiler so previously network would always use stdcall as the calling convention triggering warnings as those in #313

This change instead uses attributes ghc puts out which already does platform recognition.

[kazu-yamamoto]

master has the following:

#if defined(mingw32_HOST_OS)
# if defined(_WIN32)
#   define CALLCONV stdcall
# else
#   define CALLCONV ccall
# endif
#else
# define CALLCONV ccall
#endif

@Mistuke What do you think?

[Mistuke]

@kazu-yamamoto that's exactly what's wrong.

It's essentially the same thing as

#if defined(mingw32_HOST_OS)
# if 1
#   define CALLCONV stdcall
# else
#   define CALLCONV ccall
# endif
#else
# define CALLCONV ccall
#endif

_WIN32 does not mean your target is a 32 bit binary, it means the binary has access to the 32 bit subsystem which is trivially true for any 32 or 64 bit Windows versions due to the Windows On Windows emulation layer.

The official documentation for this macro[1] states:

_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.

and the mingw documentation[2] for it:

Identification | _WIN32 | Defined for both 32-bit and 64-bit environments 1

[1] https://msdn.microsoft.com/en-us/library/b0084kay.aspx
[2] https://sourceforge.net/p/predef/wiki/OperatingSystems/

This common misconception is why in GHC we avoid the use of these Macros and instead define less ambiguous ones used in the PR.

[kazu-yamamoto]

@Mistuke I'm sorry. I was confused. #313 discusses 2.6 while this PR is for master.
Now I understand your intention.

But I should ask one more question. Why doesn't AppVeyor produce this warnings? If my understanding is correct, we are using 64bit Windows on AppVeyor.

[Mistuke]

But I should ask one more question. Why doesn't AppVeyor produce this warnings? If my understanding is correct, we are using 64bit Windows on AppVeyor.

It's because someone screwed up https://ghc.haskell.org/trac/ghc/ticket/14946 , which means that _WIN32 is always undefined. which means ccall is always being used. So 64 bit is correct by chance, but 32 bit is corrupting the stack frame. You won't get a warning for it since ccall is of course a valid calling convention on 32 bit Windows.

Since changing to this new approach over the buildinfo one network is subtly broken on x86 now due to this since cc-options is added after the -undef call to the pre-processor. Though the undefined error from #313 could be haskell/cabal#4435 but that raises the question why it's worked before...

Using the Haskell compiler defines in Haskell sources seems to be the most backwards compatible way to fix this.

[kazu-yamamoto]

LGTM

[kazu-yamamoto]

I have merged this. Thank you!