Fix warnings from cross-compiling with x86_64-w64-mingw32-gcc-posix

[cary-ilm]

• MSVCRT doesn't recognize printf("%l") so PRIu64 doesn't work, it expects "%I64u".
• Add to the cases that disable a strncpy warning
• Use "%zu" for printing size_t

[meshula]

I wish we had a solution that for the strncpy that doesn't trigger warnings, such as writing out own strncpy variant, but I'm fine with punting a deeper think about that for later in order to clean up warnings now.

[meshula]

Does the MSVC warning go away if the str[len]='\0' line is copied immediately after the strncpy? I wonder if the compiler is smart enough to see that.

[kmilos]

Btw, __MSVCRT__ seems to be defined even in more modern/compliant UCRT environments like UCRT64 and CLANG64, where I didn't see this warning before... Perhaps this should be checking for && !defined(_UCRT) in addition?

This is from my _mingw.h:

#if !defined(_UCRT) && ((__MSVCRT_VERSION__ >= 0x1400) || (__MSVCRT_VERSION__ >= 0xE00 && __MSVCRT_VERSION__ < 0x1000))
/* Allow both 0x1400 and 0xE00 to identify UCRT */
#define _UCRT
#endif

• On UCRT64 and CLANG64 (using UCRT), __MSVCRT_VERSION__ is 0xE00 so _UCRT is defined.
• On recent MINGW64 (using MSVCRT), __MSVCRT_VERSION__ is 0x700, so it is not defined.
• On older Debian/Ubuntu mingw cross toolchains targeting MSVCRT, either the statement is not in the old _mingw.h so _UCRT is not defined anyway, or __MSVCRT_VERSION__ is also at a lower version.

[kmilos]

FWIW, I don't get any print format or string warnings on either main or 3.2.0 tag using the native and up to date MSYS2 MINGW64 environment. (I'm only seeing deprecation warnings.)

P.S. Again, adding MSYS2 builds (e.g. MINGW64 + CLANG64 as minimum) to your CI would be beneficial and easy ;)

[cary-ilm]

I reverted the blank line, but otherwise I'm inclined to leave strncpy alone for now (with the further pragmas). There's no suggestion that the code is incorrect, just that come compilers are being extra persnickety. Conceivably we could replace these strncpy's with memcpy's with the proper length calculations, but we'll leave that for another day.