混合引用"stdio.h"与<cstdio>触发GCC警告及跨C/C++头文件疑问

这个问题是32位版本MinGW-W64的头文件宏定义逻辑和运行时实现不匹配导致的，具体逻辑如下：

1. 32位i686架构的MinGW-W64默认兼容微软MSVCRT运行时，MSVCRT的printf在32位环境下不支持C标准的%lld格式符，只支持微软自定义的%I64d来输出64位整数。
2. 当你先包含C标准的stdio.h时，MinGW的stdio.h默认不会开启ANSI格式化兼容宏__USE_MINGW_ANSI_STDIO，此时<cinttypes>中的PRId64会被展开为"lld"，GCC的格式化检查逻辑默认对齐MSVCRT的实现，就会判定%lld是非法格式符，触发警告。
3. 如果你只包含C的<cstdio>，不提前引入stdio.h，<cstdio>作为C标准头文件会默认定义__USE_MINGW_ANSI_STDIO 1，一方面会让编译器用MinGW自行实现的ANSI兼容版printf（支持%lld），另一方面也会让格式化检查逻辑识别%lld为合法符，就不会触发警告。
4. 你示例代码中先包含stdio.h再包含<cstdio>时，stdio.h的头文件守卫已经生效，<cstdio>的宏定义逻辑没有机会执行，因此还是会走默认的MSVCRT对齐逻辑，触发警告。

不需要强制C++代码放弃<cstdio>，可以用以下任意一种方案解决兼容问题：

• 方案1：在公共头文件的最顶部，所有标准库引入之前，添加宏定义#define __USE_MINGW_ANSI_STDIO 1。这个宏对C和C++编译器都生效，会让整个项目的格式化逻辑统一对齐ANSI标准，不管是引入stdio.h还是<cstdio>都不会出现格式符不匹配的问题。
• 方案2：在C++代码中，调整头文件引入顺序，先引入<cstdio>，再引入公共头文件。先引入<cstdio>已经完成了宏配置和stdio.h的加载，后续公共头文件再引入stdio.h时会触发头文件守卫直接跳过，不会覆盖已经生效的正确配置。
• 方案3：如果项目需要兼容微软原生MSVC编译器，可以统一用微软风格的格式符%I64d替代PRId64，不过这种方案会损失跨POSIX平台的兼容性，按需选择即可。

内容的提问来源于stack exchange，提问作者jgreen81