为什么printf实现者更喜欢打印带有前导1的“％a”数字？

如何解决为什么printf实现者更喜欢打印带有前导1的“％a”数字？

最近，我编写了以下程序来测试使用%a说明符打印不同的浮点类型：

#include <stdio.h>
#include <stdlib.h>
#define ELEM(x)   { #x,x }
#define FLT_C(x)  ELEM(x##f)
#define DBL_C(x)  ELEM(x)
#define LDBL_C(x) ELEM(x##L)
#define TEST(TYPE,C,PRI) do { \
    /* some random numbers,do not matter really */ \
    const struct { const char *str; TYPE val; } nums[] = { \
        C(123.456),C(456.789),\
        C(123.678e10),C(678.890e-10),\
        C(1/0.3),C(0.5) \
    }; \
    /* foreach number in nums */ \
    for (size_t i = 0; i < sizeof(nums)/sizeof(*nums); ++i) { \
        printf("%15s %-20s = %"PRI"a\n",#TYPE,nums[i].str,nums[i].val); \
        /*                     ^^^^^^^ - print with %a with proper specifier */ \
    } \
} while(0)

int main() {
    printf("%38s\n",#if defined __GLIBC__
    "GLIBC"
#elif defined __NEWLIB__
    "NEWLIB"
#else
    "alpine"
#endif
    );
    TEST(float,FLT_C,"");
    TEST(double,DBL_C,"l");
    TEST(long double,LDBL_C,"L");
}

我使用手头的各种标准库实现来运行程序（Godbolt link）：

$ gcc -Wall -Wextra /tmp/1.c && ./a.out && arm-none-eabi-gcc --specs=rdimon.specs -u_printf_float -u_scanf_float -specs=nosys.specs /tmp/1.c && qemu-arm /tmp/a.out && docker run -ti --rm -v /tmp/1.c:/tmp/1.c:ro alpine sh -c 'apk add build-base >/dev/null && gcc /tmp/1.c && ./a.out'
                                 GLIBC
          float 123.456f             = 0x1.edd2f2p+6
          float 456.789f             = 0x1.c8c9fcp+8
          float 123.678e10f          = 0x1.1ff5d6p+40
          float 678.890e-10f         = 0x1.2394bep-24
          float 1/0.3f               = 0x1.aaaaaap+1
          float 0.5f                 = 0x1p-1
         double 123.456              = 0x1.edd2f1a9fbe77p+6
         double 456.789              = 0x1.c8c9fbe76c8b4p+8
         double 123.678e10           = 0x1.1ff5d523p+40
         double 678.890e-10          = 0x1.2394beb1a4116p-24
         double 1/0.3                = 0x1.aaaaaaaaaaaabp+1
         double 0.5                  = 0x1p-1
    long double 123.456L             = 0xf.6e978d4fdf3b646p+3
    long double 456.789L             = 0xe.464fdf3b645a1cbp+5
    long double 123.678e10L          = 0x8.ffaea918p+37
    long double 678.890e-10L         = 0x9.1ca5f58d208ac05p-27
    long double 1/0.3L               = 0xd.555555555555555p-2
    long double 0.5L                 = 0x8p-4
                                NEWLIB
          float 123.456f             = 0x1.edd2f2p+6
          float 456.789f             = 0x1.c8c9fcp+8
          float 123.678e10f          = 0x1.1ff5d6p+40
          float 678.890e-10f         = 0x1.2394bep-24
          float 1/0.3f               = 0x1.aaaaaap+1
          float 0.5f                 = 0x1p-1
         double 123.456              = 0x1.edd2f1a9fbe77p+6
         double 456.789              = 0x1.c8c9fbe76c8b4p+8
         double 123.678e10           = 0x1.1ff5d523p+40
         double 678.890e-10          = 0x1.2394beb1a4116p-24
         double 1/0.3                = 0x1.aaaaaaaaaaaabp+1
         double 0.5                  = 0x1p-1
    long double 123.456L             = 0x1.edd2f1a9fbe77p+6
    long double 456.789L             = 0x1.c8c9fbe76c8b4p+8
    long double 123.678e10L          = 0x1.1ff5d523p+40
    long double 678.890e-10L         = 0x1.2394beb1a4116p-24
    long double 1/0.3L               = 0x1.aaaaaaaaaaaabp+1
    long double 0.5L                 = 0x1p-1
                                alpine
          float 123.456f             = 0x1.edd2f2p+6
          float 456.789f             = 0x1.c8c9fcp+8
          float 123.678e10f          = 0x1.1ff5d6p+40
          float 678.890e-10f         = 0x1.2394bep-24
          float 1/0.3f               = 0x1.aaaaaap+1
          float 0.5f                 = 0x1p-1
         double 123.456              = 0x1.edd2f1a9fbe77p+6
         double 456.789              = 0x1.c8c9fbe76c8b4p+8
         double 123.678e10           = 0x1.1ff5d523p+40
         double 678.890e-10          = 0x1.2394beb1a4116p-24
         double 1/0.3                = 0x1.aaaaaaaaaaaabp+1
         double 0.5                  = 0x1p-1
    long double 123.456L             = 0x1.edd2f1a9fbe76c8cp+6
    long double 456.789L             = 0x1.c8c9fbe76c8b4396p+8
    long double 123.678e10L          = 0x1.1ff5d523p+40
    long double 678.890e-10L         = 0x1.2394beb1a411580ap-24
    long double 1/0.3L               = 0x1.aaaaaaaaaaaaaaaap+1
    long double 0.5L                 = 0x1p-1

我测试了3种实现，除long double以外的所有glibc都用前导0x1打印十六进制浮点数...为什么使用0x1？

有3种不同的实现方式选择0x1作为打印十六进制浮点数的初始部分的特定原因吗？它简化了某些事情吗？这是由某些标准强制执行的吗？为什么不总是从初始位（即0x8/0x9/.../0xf）开始，然后以-3来调整指数呢？这样，在某些情况下，表示将更短。

源代码研究：glibc just prints '1' in printf_fphex#285，newlib just prints '1' in cfprintf#L1746和musl does frexpl()*2 in fmt_fp#L210 before converting to digits。是否有任何原因使首字母0x1如此重要，以至于实现特别希望打印首字母1？（另外，为什么带long double的glibc不这样做？）

@edit添加了1/3.0L。以下是long double s的较小并排比较：

v>      123.456L                 456.789L                 123.678e10L       678.890e-10L              1/0.3L                   0.5L
GLIBC   0xf.6e978d4fdf3b646p+3   0xe.464fdf3b645a1cbp+5   0x8.ffaea918p+37  0x9.1ca5f58d208ac05p-27   0xd.555555555555555p-2   0x8p-4
MUSL    0x1.edd2f1a9fbe76c8cp+6  0x1.c8c9fbe76c8b4396p+8  0x1.1ff5d523p+40  0x1.2394beb1a411580ap-24  0x1.aaaaaaaaaaaaaaaap+1  0x1p-1
NEWLIB  0x1.edd2f1a9fbe77p+6     0x1.c8c9fbe76c8b4p+8     0x1.1ff5d523p+40  0x1.2394beb1a4116p-24     0x1.aaaaaaaaaaaabp+1     0x1p-1

解决方法

这很可能是因为大多数实现都将IEEE754表示形式用于浮点数。

此表示形式显式存储许多精度位（单精度为23，双精度为52），以及一个始终为1的隐式位。因此，始终在基数点的左侧打印值1，即可得到这些值。右边的位置恰好与表示形式的精度部分相对应。这样可以更轻松地调试以这种格式存储的值。

为什么printf实现者更喜欢打印％a开头的数字？

首先，所有实现都符合C规范^*。

...表示浮点数的double参数以以下格式转换 [-] 0xh.hhhhp + -d，其中小数点字符前有一个十六进制数字（如果参数是规范化的浮点数，则为非零，否则为非指定），十六进制数字等于该数字后的十六进制数字精确到如果缺少精度，并且FLT_RADIX是2的幂，则精度足以表示该值； ... C17§7.21.6.1 8

使用double常数会使测试模糊。最好在常量后附加L：（123.456-> 123.456L）。照原样，对于long double nums[]，在打印时保存为long double的所有值都具有尾随零精度位，而"%La"则在打印时尾随有效的'0'而后。

在long double 1.234560e+02情况下，0xf.6e978d4fdf3b8p+3和0x1.edd2f1a9fbe77p+6均为53个有效数字。

我认为实现的理性使用1或1 to F来实现 1个2个目标：

对于非零有限值，始终以1开头。如果FP有效位数不是4 * n + 1位数，则第n 个十六进制数将不使用全部16个选择。（我称此为左对齐）。
具有[1到F或更小]的非零有限值，以便全精度输出（例如，用于选择long double的64位）可以使用最低有效十六进制中的所有16个选择数字。（我称这种权利为正。）

对于GLIBC long double，（假设10位扩展FP）该值具有一些非零的尾随精度位（使用L），我希望它会打印出来重要数字为16个十六进制数字，而其他数字则为17个十六进制数字。

我看到第一个偏爱“使用1”，因为它更容易解释：“对于非零有限值，总是以1开头。”

^*，除外，也许long double在至少{em> 的NEWLIB情况下无法以足够的精度打印（根据我使用L进行的测试）。我将对此进行更多研究。

为什么printf实现者更喜欢打印带有前导1的“％a”数字？

如何解决为什么printf实现者更喜欢打印带有前导1的“％a”数字？

解决方法

相关推荐