Win10下CodeBlocks20.03 MinGW-W64 GCC8.1.0打印LDBL_MAX/LDBL_MIN异常

• 这是Windows平台MinGW工具链的经典历史兼容坑，和你的测试代码逻辑没有关系。
• 你预期的10^4932量级，是x86架构下80位扩展精度long double的正常取值范围，要正确打印这两个宏值，需要同时满足两个条件：一是编译器按80位扩展精度规则生成long double数据，二是链接的C运行时能正确识别%Lf、%Le这类带长修饰符的格式占位符。
• CodeBlocks 20.03内置的MinGW-W64 GCC 8.1.0，默认是链接Windows系统自带的MSVCRT系统C运行时的——这套运行时是微软早年为兼容传统Win32程序设计的，从设计根源上就不支持x86 80位扩展精度long double的格式化解析。
• 你看到sizeof(long double)返回16字节，是内存对齐带来的假象：80位（也就是10字节）的扩展精度浮点数，在栈上存储时会按照16字节的边界做对齐填充，因此求大小时会返回16，但这根本不代表运行时能正确处理这个类型。

你实际看到的3.17e-317量级的输出，是参数解析错位导致的无效结果：GCC按照x86的函数调用约定，把80位long double的二进制内容压入栈传递给printf，但MSVCRT的printf完全识别不了80位长双精度的二进制格式，直接把栈上对应位置的字节强行按照64位double的规则去解析，拼出来的自然是和真实LDBL_MIN、LDBL_MAX完全无关的异常小值。

• 额外说明：MinGW-W64本身有两套可切换的long double编译ABI，部分旧版本默认会把long double直接映射为64位double类型，这种场景下就算解析不出错，取值范围也达不到10^4932的量级。但你遇到的情况里sizeof结果符合16字节的对齐规则，核心矛盾仍然是MSVCRT运行时对长双精度格式化输出的支持缺失。

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