c - 如何让 MinGW GCC 识别 size_t 的 %zu 格式说明符？

Question

一张图片胜过一千个文字:

我知道如何解决该问题。但是我如何在 Microsoft 中修复它，这样我就不会收到警告？

编辑:

1. 与其他人在评论中指出的相反，这是特定于Microsoft系统的。我可以在 Linux 机器上运行完全相同的代码，在具有相同配置(tasks.json 和 properties.json)的相同版本的 VsCode 中使用它，使用相同版本的 gcc，并且我不会收到这些编译器警告.
2. 我使用的 C 标准是 c17。
3. 尝试在格式相关函数(如 printf 和 scanf)中使用“%z”(甚至“%ll”)等格式说明符将触发格式编译器警告，即使是在完全更新的版本中(截至 2021 年 8 月) Windows 10 操作系统，具有最新的 mingw-64 工具链(具体来说，gcc 8.1.0 - 这是此处使用的编译器)。
4. 图像中显示的“编译器错误”实际上只是一个被视为错误的格式警告(引用编译器:“[-Werror=format=] ”)
5. 谢谢，“@the busybee”。你试图解决这个问题。这确实是一个很好的解决方法，但它会影响开发兼容性。

编辑2:

在遇到导致实际意外错误的格式不兼容问题(以及在 Windows 上使用 GDB 高级功能的可怕经历之后)，我决定在 Windows 上永远放弃 GNU。对于 Windows 机器上的 C 跨平台开发，我现在使用 Clang。到目前为止，我对这个决定百分百满意。感谢所有花时间帮助我的人。

Answer 1

值得指出这里的根本问题是什么，即:严重、公然违反 "don't repeat yourself"原则。我们有一个库函数 printf，它在运行时将解析其格式字符串并尝试打印一些内容。然后我们在 C 编译器中有一段完全不同的代码，它将在编译时解析相同的格式字符串，并警告用户潜在的问题。

对于 Windows 下的 MinGW，问题变得更加复杂，因为两个解析器是由两组完全不同的人编写和维护的，他们之间没有任何联系。 (至少在 Linux 下，从事 gcc 工作的人和从事 glibc 工作的人之间有大量的协调。)

因此，两个解析器之间对于接受的内容没有完全一致也就不足为奇了。 (事实上​​，如果完全一致那将是一个奇迹。) this question 的答案详细描述一下2012年的协调有多么不完美，10年后的今天，它仍然不完美。

不完美就是游戏的名称，可能没有完美的解决方案。我必须相信，到 2021 年，微软的 C 运行时库确实支持%zu。但是，如果 MinGW 内置的最新版本的 gcc 还没有 catch 这一事实，如果它仍然警告不支持 z 修饰符，那么您可能无能为力。您可以向 MinGW 人员发送错误报告，他们最终可能会采取行动，但同时您已经获得了今天需要编译的代码。您可以关闭 -Wformat，但您可能不想这样做(事实上我也不想这样做)，因为您可能希望 -Wformat 继续检查其他错误你可能会做。

我是维护大型、成熟、跨平台代码库的团队的一员，尽管这是我非常想使用的理想解决方案，但我们仍然不经常使用%zu，因为我们仍然无法确定我们使用的每个编译器和每个运行时库都同意它。

我这么说并不是建议您也放弃 %zu，而只是表达我的同情:即使在 2021 年，printf size_t 仍然非常困难> 值安全且便携。