C程序转换为Windows后显示%zu [英] C program shows %zu after conversion to Windows

问题描述

我通过 Mingw 在 Windows 上编译了一个 linux 程序.但是，程序的输出在 Windows 上看起来与在 Linux 上不同.

I complied a linux program on windows via Mingw. However, the output of the program looks different on Windows than on Linux.

例如，在 Windows 上，输出是这样的(我得到的是 'zu' 而不是实数):

For example, on Windows the output is this (I get 'zu' instead of real numbers):

Approximated minimal memory consumption:
Sequence        : zuM
Buffer          : 1 X zuM = zuM
Table           : 1 X zuM = zuM
Miscellaneous   : zuM
Total           : zuM

在 Linux 上，原始程序编译(没有 Mingw)时会出现警告.在 Windows 上，在 Mingw 下，它以零警告编译.

On Linux, the original program compiles (without Mingw) with a warning. On Windows, under Mingw, it compiles with zero warnings.

有什么需要注意的吗?
Mingw 是否提供 100% 的兼容性，或者我必须修改程序才能在 Win 上运行?

There is anything I should be aware about?
Does Mingw offer 100% compatibility or I have to modify the program to work on Win?

我不知道该往哪个方向走.我应该从哪里开始尝试修复程序?
你认为我使用 Cygwin 有更好的机会吗?

I don't know in which direction to head. Where should I start my attempt of fixing the program?
Do you think I have better chances with Cygwin?

更新:
维基百科提到这一点:缺乏对 C99 的支持导致了移植问题，特别是在涉及 printf 样式转换说明符的情况下".
这就是我撞到头的东西吗?

Update:
Wikipedia mentions this: "the lack of support for C99 has caused porting problems, particularly where printf-style conversion specifiers are concerned".
Is this the thing in which I bumped my head?

更新:
我的mingw版本是:

Update:
My mingw version is:

MINGWBASEDIR=C:MinGW
gcc version 4.8.1 (GCC)
gcc version 4.8.1 (GCC)
GNU gdb (GDB) 7.6.1
GNU ld (GNU Binutils) 2.24
GNU windres (GNU Binutils) 2.24
GNU dlltool (GNU Binutils) 2.24
GNU Make 3.82.90
#define __MINGW32_VERSION           3.20
#define __W32API_VERSION 3.17

(我使用此代码获取版本:

(I used this code to get the version:

@echo off
REM version-of-mingw.bat
REM credit to Peter Ward work in ReactOS Build Environment RosBE.cmd it gave me a starting point that I edited.
::
:: Display the current version of GCC, ld, make and others.
::

REM %CD% works in Windows XP, not sure when it was added to Windows
REM set MINGWBASEDIR=C:MinGW
set MINGWBASEDIR=%CD%
ECHO MINGWBASEDIR=%MINGWBASEDIR%
SET PATH=%MINGWBASEDIR%in;%SystemRoot%system32
if exist %MINGWBASEDIR%ingcc.exe (gcc -v 2>&1 | find "gcc version")
REM if exist %MINGWBASEDIR%ingcc.exe gcc -print-search-dirs
if exist %MINGWBASEDIR%inc++.exe (c++ -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%ingcc-sjlj.exe (gcc-sjlj.exe -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%ingcc-dw2.exe (gcc-dw2.exe -v 2>&1 | find "gcc version")
if exist %MINGWBASEDIR%ingdb.exe (gdb.exe -v | find "GNU gdb")
if exist %MINGWBASEDIR%in
asm.exe (nasm -v)
if exist %MINGWBASEDIR%inld.exe (ld -v)
if exist %MINGWBASEDIR%inwindres.exe (windres --version | find "GNU windres")
if exist %MINGWBASEDIR%indlltool.exe (dlltool --version | find "GNU dlltool")
if exist %MINGWBASEDIR%inpexports.exe (pexports | find "PExports" )
if exist %MINGWBASEDIR%inmingw32-make.exe (mingw32-make -v | find "GNU Make")
if exist %MINGWBASEDIR%inmake.exe (ECHO It is not recommended to have make.exe in mingw/bin)
REM ECHO "The minGW runtime version is the same as __MINGW32_VERSION"
if exist "%MINGWBASEDIR%include\_mingw.h" (type "%MINGWBASEDIR%include\_mingw.h" | find "__MINGW32_VERSION" | find "#define")
if exist "%MINGWBASEDIR%includew32api.h" (type "%MINGWBASEDIR%includew32api.h" | find "__W32API_VERSION")

:_end
PAUSE

)

推荐答案

根据 评论中链接的错误报告讨论，Microsoft 的printf 函数不支持C99.如果宏 __USE_MINGW_ANSI_STDIO 在包含任何标题之前或在命令行上设置为 1，mingw-w64 项目提供替代函数，它们可以像普通 C99 函数一样使用.它们支持标准的 %zu、%jd 等格式说明符，即使是最新的 MSVCRT 版本也不支持.您可以直接使用 mingw_printf 调用该函数，但通常将上述宏定义为 1 并调用 printf 等通常更容易.

As suggested by the bug report discussion linked in the comments, Microsoft's printf functions do not support C99. The mingw-w64 project provides alternative functions that may be used as if they were the normal C99 functions if the macro __USE_MINGW_ANSI_STDIO is set to 1 either before including any headers or on the command line. They support the standard %zu, %jd, etc. format specifiers that even the newest MSVCRT versions do not. You may invoke the function directly using mingw_printf, but it is usually easier to just define the aforementioned macro to 1 and call printf, etc.

值得注意的是，如果你使用微软的snprintf，如果缓冲区不够大，它会返回-1表示截断，除非缓冲区和缓冲区大小参数为NULL 和 0，在这种情况下，将返回将输出的字节数.C99 的行为是，如果缓冲区足够大，则始终返回将输出的字节数，或者如果发生编码错误，则返回负值，并且 mingw-w64 实现似乎根据 C99 表现正确.

It is worth noting that if you use Microsoft's snprintf, it will return -1 to indicate truncation if the buffer is not large enough, unless the buffer and buffer size parameters are NULL and 0 respectively, in which case the number of bytes that would be output is returned. C99 behavior is to always return the number of bytes that would be output if the buffer was sufficiently large, or a negative value if an encoding error occurs, and the mingw-w64 implementation seems to behave correctly according to C99.

如果您使用任何 printf 函数或简单地添加-D__USE_MINGW_ANSI_STDIO=1 到您的编译器调用.

And all you need to do to get all of this standard behavior is either #define __USE_MINGW_ANSI_STDIO 1 before any includes if you use any of the printf functions or simply add -D__USE_MINGW_ANSI_STDIO=1 to your compiler invocation.

如果您担心宏会干扰其他平台，那么除了提供类似功能的原始(旧版?)MinGW[32] 项目之外，没有其他实现实际上应该使用此预处理器宏，因此定义它是安全的无条件的.

If you are worried about the macro interfering with other platforms, no other implementation except the original (legacy?) MinGW[32] project that provided similar functionality should actually make use of this preprocessor macro, so it is safe to define it unconditionally.

这篇关于C程序转换为Windows后显示%zu的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！