问题描述
最近，我编写了以下程序来测试使用%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进行的测试）。我将对此进行更多研究。