在编译器之间从 printf() 获得一致的输出

如何解决在编译器之间从 printf() 获得一致的输出

我注意到 printf("%#g\n",0.0) 在任何 gcc/clang 版本与 Windows 7 上的 Visual Studio 2019（截至今天的最新版本）下提供不同的输出。

gcc/clang 给出 0.00000（总共 6 位数字，. 之后的 5 位）而 VS 给出 0.000000（总共 7 位，. 之后的 6 位）。同样，"%#.8g" 使用 gcc/clang 给出总共 8 位数字，而使用 VS 给出总共 9 位数字。

问题：

• 标准对此有何规定？编译器/标准库之一有问题吗？
• 我只在本地的 VS (Windows 7) 上看到这种行为，但在 Azure Pipelines（最近的 Windows Server）上看不到。哪些特定的编译器版本/标准库版本/操作系统会受到影响？
• 有没有办法在编译器之间获得一致的输出？

解决方法

这是一个错误

您在 Visual Studio 中使用的 C 实现有缺陷。以下引文来自 C 2018。相关文本在 2011 和 1999 标准中实际上相同（在 1999 年，不等式使用文本而不是使用“>”和“≥”的数学符号进行描述）。

首先，在这种情况下，# 表示将生成小数点字符并且不会删除尾随零。它对删除尾随零之前应生成的位数没有影响。 7.21.6.1 6 说“……对于a、A、e、E、f、F、g，和 G 转换，转换浮点数的结果总是包含一个小数点字符，即使后面没有数字......对于 g 和 G 转换，尾随零不是从结果中删除...”这使 g 规范的一部分无效，即“...除非使用 # 标志，否则将从结果的小数部分和小数点中删除任何尾随零如果没有剩余的小数部分，则删除字符。”

其次，对于零值，g 格式的规则规定使用 f 格式。这是因为 g（或 G）的规则取决于 e 格式将使用的指数和要求的精度：

• 对于 e，7.21.6.1 8 表示“……如果值为零，则指数为零。”
• 对于g，它说“……如果非零，则让 P 等于精度，如果省略精度，则为 6，如果精度为零，则为 1……”所以 P 在问题中给出的 %#g 或 %#.8g 中是 6 或 8。
• 文本继续“……如果 P > X ≥ −4，则转换采用样式 f（或 F）和精度P - (X + 1)。”

所以 %#g 或 %#.8g 的转换是通过样式 f 分别使用精度 6−(0+1) = 5 或 8−(0+1) = 7 完成的.

第三，对于 f，7.21.6.1 8 说“表示浮点数的 double 参数被转换为 [-]ddd.ddd 样式中的十进制表示法 em>，其中小数点字符后的位数等于精度规范……”因此，应分别打印小数点后的 5 位或 7 位数字。

因此，对于 %#g，“0.00000”符合 C 标准而“0.000000”不符合。而对于%#.8g，共八位（小数点后七位）符合，九位（小数点后八位）不符合。

既然你用visual-c++标记了这个，我会注意到C++标准采用了printf的C规范。 C 2017 草案 N4659 20.2 说“C++ 标准库还提供了 C 标准库的功能，经过适当调整以确保静态类型安全。”

补偿错误

bug 可能是在 C/C++ 库，而不是编译器，所以调整源代码，例如使用 #if 来测试微软的宏 _MSC_VER 的值，很可能不是很好的解决方案。 （特别是，在编译之后，编译器可能会与更高版本的库一起运行。）

可以在程序启动期间测试库。使用外部作用域定义 int PrecisionAdjustment; 后，可以使用此代码对其进行初始化：

{
    /*  The following tests for a Microsoft bug in which a "%#g" conversion
        produces one more digit than the C standard specifies.  According to
        the standard,formatting zero with "%#.1g" should produce "0.",but
        Microsoft software has been observed to produce "0.0".  If the bug
        appears to be present,PrecisionAdjustment is set -1.  Otherwise,it is 0.  This can then be used to select which format string to
        use or to adjust a dynamic precision given with "*" such as:

            printf("%#.*g",6+PrecisionAdjustment,value);
    */
    char buffer[4];
    snprintf(buffer,sizeof buffer,"%#.1g",0.);
    PrecisionAdjustment = buffer[2] == '0' ? -1 : 0;
}

这假设我们在精度 6 和 8 中看到的相同错误存在于精度 1 中。否则，可以轻松进行适当的调整。

,

您询问是否有办法在编译器之间获得一致的输出。我怀疑是否有直接的方法，我知道这有多令人沮丧。如果额外的 0 数字导致您出现问题并且必须修复，您将不得不采用某种解决方法。在这种情况下，我可以想象三种截然不同的方法。

1. 如果 Visual Studio 仅在尝试打印默认位数时出现错误，请尝试明确指定位数。也就是说，您可以尝试使用 "%#g" 代替 "%#.6g"。如果这在两个平台上给您相同的结果，您就大功告成了。

2. 如果 Visual Studio 总是多打印一位数字，您可以尝试在 Visual Studio 下使用与其他平台不同的格式，使用条件编译 (#ifdef) 选择要使用的格式.如果 Visual Studio 仅在打印的值为 0.0 时出现问题，您可能还需要为此进行运行时测试。

3. 您可以使用 printf 代替 snprintf，然后使用字符串函数（可能是 strstr）查看缓冲区是否错误地以 {{1} 结尾}}，如果是，则将其截断一个字符。

如果方法 #1 有效，那就太好了。否则，我会强烈鼓励你使用方法#3，即使它（我承认）是一个很大的、丑陋的麻烦。但如果可能，请远离方法#2。它有两个巨大的问题：(1) 条件编译最终成为一个更大、更丑陋的麻烦。许多风格指南建议——非常正确地——避免它。 (2) 方法#2 的更大问题是，如果 Microsoft 修复了他们的 printf 版本以使其正常运行，那么您的代码可能会在那时中断，也许您没有注意到！方法#2 与“未来证明”相反。

或者，换句话说，“不要把你必须解决的错误放在首位”。