Re^4: [XS] : "snprintf" portability options

The warning is spurious, %I64u is valid on Windows. Unfortunately with the macro the full text of the format is hidden so all you have is the misleading "%u" from the base message:

C:\Users\Tony\dev\perl\git>gcc -Wformat -oint64.exe int64.c
int64.c: In function 'main':
int64.c:6:15: warning: format '%u' expects argument of type 'unsigned 
+int', but argument 2 has type 'long long unsigned int' [-Wformat=]
    6 |   printf("%I64u\n", x);
      |           ~~~~^     ~
      |               |     |
      |               |     long long unsigned int
      |               unsigned int
      |           %I64llu

C:\Users\Tony\dev\perl\git>type int64.c
#include <stdio.h>

unsigned long long x = 0;

int main() {
  printf("%I64u\n", x);
}
[download]

If it is a bug, it's a bug in perl, since that's where the macro OP is using comes from.

I've considered changing the Win32 config in perl to use "%llu"/"%lld" instead, but testing against the older versions of MSVCRT in older Windows that we theoretically support is difficult.

Comment on Re^4: [XS] : "snprintf" portability options Select or Download Code

Replies are listed 'Best First'.
Re^5: [XS] : "snprintf" portability options by NERDVANA (Priest) on Sep 17, 2024 at 01:34 UTC
If it is a bug, it's a bug in perl Don't you mean a bug in gcc? gcc knows it is building for the MS libc, so it should accept the patterns known to work for that libc.	[reply]
Re^6: [XS] : "snprintf" portability options by tonyc (Hermit) on Sep 17, 2024 at 04:41 UTC
I was looking at it from the point of view that the "%I64u" format is incorrect, though it works and perl's own implementation of formatted output emulates it. If I could be sure old MSVCRT supported "%llu" I'd make a PR switching it to the standard form, since it would let us turn on -Wformat and better detect format issues on the specialness that is Win32. And reduce confusion from people wondering what this I64 format business is.	[reply]
Re^7: [XS] : "snprintf" portability options by syphilis (Archbishop) on Sep 17, 2024 at 07:49 UTC
If I could be sure old MSVCRT supported "%llu" I'd make a PR switching it to the standard form Would it be feasible to allow for both models in the source, and then base the decision on which model to implement by information gathered during the early stages of the gmake/nmake stage ? For example, would the fact that the toolchain uses UCRT alone imply that "%llu" is supported ? Or could a "configure" type C script be run to probe whether "%llu" is supported ? Cheers, Rob	[reply]
Re^5: [XS] : "snprintf" portability options by ikegami (Patriarch) on Sep 17, 2024 at 10:25 UTC
Bad test. You just repeated what was already said. But replacing `0` with `9223372036854775808ull` does make your point. So the compiler is wrong about the expected format. wow! And thankfully, it still provides the expected format. If it is a bug, it's a bug in perl It's a bug in gcc. The format expects a `unsigned long long`, but it claims it expects an `unsigned`.	[reply] [d/l] [select]