Implement various Windows build fixes

[braewoods]

This also closes #12.

[hhromic]

Hi @braewoods , thanks for the contribution and helping on the Windows front! 💯

Your changes looks good but I have the following two questions:

• For setsockopt, according to POSIX and Windows the fourth argument should be qualified with const. Therefore, can you update your changes for (const void *) instead? Thanks for spotting this one!
• The same above applies to sendto as well for the second argument.
• Can you elaborate on why you need to switch the PRIu32 format to lu? I just tested a simple program in MSYS2 (which I also use) and it works fine for the output of ntohl. The PRIu32 format macro is supposed to be portable.

[braewoods]

* For `setsockopt`, according to [POSIX](https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/setsockopt.html) and [Windows](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-setsockopt) the fourth argument should be qualified with `const`.  Therefore, can you update your changes for `(const void *)` instead? Thanks for spotting this one!
* The same above applies to `sendto` as well for the second argument.

Fair, but I didn't think it would matter in practice because non-const variables will get silently promoted to const in such contexts.

* Can you elaborate on why you need to switch the `PRIu32` format to `lu`? I just tested a simple program in MSYS2 (which I also use) and it works fine for the output of `ntohl`. The `PRIu32` format macro is supposed to be portable.

I was getting compiler warnings on the UCRT64 toolchain because ntohl returns an unsigned long, where as PRIu32 resolves to a printf specifier for unsigned int. In practice this should not matter for Windows because long and int are the same size even on 64 bit Windows, but this is the ABI Microsoft decided on, and I have no idea why GCC is even warning for it.

[braewoods]

First set of changes done.

[braewoods]

Here's the errors I was getting without my changes:

src/e131.c:316:19: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'u_long' {aka 'long unsigned int'} [-Werror=format=]
  316 |   fprintf(stream, "  Layer Vector ........... %" PRIu32 "\n", ntohl(packet->root.vector));
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~              ~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                               |
      |                                                               u_long {aka long unsigned int}
In file included from src/e131.c:26:
C:/msys64/ucrt64/include/inttypes.h:101:17: note: format string is defined here
  101 | #define PRIu32 "u"
src/e131.c:327:19: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'u_long' {aka 'long unsigned int'} [-Werror=format=]
  327 |   fprintf(stream, "  Layer Vector ........... %" PRIu32 "\n", ntohl(packet->frame.vector));
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~              ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                               |
      |                                                               u_long {aka long unsigned int}
C:/msys64/ucrt64/include/inttypes.h:101:17: note: format string is defined here
  101 | #define PRIu32 "u"```

[hhromic]

Fair, but I didn't think it would matter in practice because non-const variables will get silently promoted to const in such contexts.

Yep, I'm aware that promotion takes place, but I prefer code to be as correct as possible, thanks for updating it!

I was getting compiler warnings on the UCRT64 toolchain because ntohl returns an unsigned long, where as PRIu32 resolves to a printf specifier for unsigned int. In practice this should not matter for Windows because long and int are the same size even on 64 bit Windows, but this is the ABI Microsoft decided on, and I have no idea why GCC is even warning for it.

Yes, I went again to check my toy example where I was testing this and I made a silly mistake. I now got the same warning you were getting and understand why too as you explained.

However, instead of #ifdef pre-processor directives, I would prefer to do a casting instead:

fprintf(stream, "  Layer Vector ........... %" PRIu32 "\n", (uint32_t) ntohl(packet->root.vector));

How does that sound to you?

[braewoods]

Fine by me. It's been changed. I just felt like the macro one was better at explaining why the code was modified for future readers, due to the WIN32 macro check.

[hhromic]

Fine by me. It's been changed. I just felt like the macro one was better at explaining why the code was modified for future readers, due to the WIN32 macro check.

Mmh yeah I think that you are right. The macro check was indeed better at explaining.
Apologies, can you revert it then to what you had before? I will approve and merge afterwards 👍.

[braewoods]

That should do it.

[hhromic]

Thanks for the contribution!