When compiling Tcl with latest mingw-w64, warnings like this arise:

tclWinSerial.c:1459:26: warning: 'I' flag used with ‘%x’ gnu_printf format [-Wformat=]
 1459 |     sprintf(channelName, "file%" TCL_I_MODIFIER "x", (size_t) infoPtr);
      |                          ^~~~~~~

So we need to handle either using gnu printf with standard modifiers, either MSVC printf with microsoft's modifiers.

Oh, this was related to XP's C runtime. I completely forgot that Tcl still supports XP, even after seeing -D_ATL_XP_TARGETING=1 on the same line of the Makefile we are discussing :-(

Well, the Makefile is patched on MSYS2-MINGW-packages build. Let's wait until TIP #592 is decided and then maybe we can stop caring about this stdio mess.

I'm closing the bug as "Remind". Removing -D__USE_MINGW_ANSI_STDIO=0 from the Makefile would be good, when possible.

Thank you.

For 8.6, we are _very_ careful about upwards compatibility, and we still support Windows XP. That gives little room to change anything. Compiling with -D__USE_MINGW_ANSI_STDIO=1 will need a whole new printf library, either that will cause the need for an additional DLL, either it makes the binary larger. It's simply not worth the risk for standard 8.6, although in an Msys2 environment it would work just fine. So, you can patch away the -D__USE_MINGW_ANSI_STDIO=0 in the Makefile, if you want, that's fine.

TIP #592 is being voted upon now, which means we are stopping support for pre-windows 7 machines for Tcl/Tk 8.7. That means we can start using "ll" in stead of "I64" on all platforms, and that would work in any __USE_MINGW_ANSI_STDIO mode. We'll see how that works out.

Thanks!

I64 works with MinGW when __USE_MINGW_ANSI_STDIO=1:

#include <stdio.h>

int main() {
  long long a = 0x1234567890123456LL;
  printf("a= %I64x\n", a);
}


$ gcc -D__USE_MINGW_ANSI_STDIO=1 mingw-stdio.c -o ms.exe && ./ms.exe
a= 1234567890123456

$ gcc -v
Using built-in specs.
COLLECT_GCC=c:\apps\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/apps/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-10.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --disable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev6, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\ -Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high\ -Wl,--stack,12582912'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Rev6, Built by MSYS2 project) 


(This is MinGW-w64, dunno about plain MinGW).

Forcing __USE_MINGW_ANSI_STDIO=0 can be problematic when Tcl/Tk are embedded in other applications that use __USE_MINGW_ANSI_STDIO=1 (which is the default for everything built by MSYS2's makepkg-mingw, for instance).

Until now, MSYS2 distributed Tcl/Tk binaries built with __USE_MINGW_ANSI_STDIO=1, so forcing __USE_MINGW_ANSI_STDIO=0 on Tcl's makefile (and placing it after CPPFLAGS/CFLAGS, which precludes the user from choosing his own setting) is a significant, possibly problematic change.

If you are sure that Tcl's impact of __USE_MINGW_ANSI_STDIO setting does not leak to the client applications and binary packages and will remain so, then we can close this issue for good.

Thanks for your work on Tlc/MinGW, I greatly appreciate it.

Óscar Fuentes, occasional maintainer of MSYS2 Tcl-related packages.

Since the gnu_printf() functions don't know about the Microsoft-specific modifiers (I/I32/I64), doing it otherwise would cause a binary incompatibility between Tcl 8.6.10 and 8.6.11. So you will have to describe the "(which brings in its own problems)". For now, closing.

The right fix for this issue it not forcing -D__USE_MINGW_ANSI_STDIO=0 (which brings in its own problems), but doing the right thing when -D__USE_MINGW_ANSI_STDIO=1. This patch achieves that:


diff -Naur tcl8.6.5-orig/win/tclWinInt.h tcl8.6.5/win/tclWinInt.h
--- tcl8.6.11-orig/win/tclWinInt.h	2016-02-25 23:12:38.000000000 +0300
+++ tcl8.6.11/win/tclWinInt.h	2016-03-03 08:47:51.129171100 +0300
@@ -57,7 +57,7 @@
 #ifndef TCL_Z_MODIFIER
 #   ifdef _WIN64
 #	if defined(__USE_MINGW_ANSI_STDIO) && __USE_MINGW_ANSI_STDIO
-#         define TCL_Z_MODIFIER        "ll"
+#         define TCL_Z_MODIFIER        "I64"
 #	else
 #         define TCL_Z_MODIFIER        "I"
 #	endif

Fixed in 8.6: [c3c046d6a00270d1]