in reply to Re^4: [XS] : "snprintf" portability options
in thread [XS] : "snprintf" portability options

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.

  • Comment on Re^5: [XS] : "snprintf" portability options

Replies are listed 'Best First'.
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.

      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