Vincent Lefevre wrote in <https://bugs.gnu.org/54785>:

> $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))'
> 0xa.c0000000000025cp-20
> 
> instead of
> 
> 0xa.cp-20

To summarize, this test case is:

printf '%a\n' 1.0251998901367188e-05

and the problem is that converting 1.0251998901367188e-05 to long double 
prints the too-precise "0xa.c0000000000025cp-20", whereas you want it to 
convert to double (which matches what most other programs do) and to 
print "0xa.cp-20" or equivalent.

> (Note that ksh uses long double internally, but does not ensure the
> round trip back to long double

Yes, ksh messes up here. However, it's more important for Coreutils 
printf to be compatible with the GNU shell, and Bash uses long double:

$ echo $BASH_VERSION
5.1.8(1)-release
$ /usr/bin/printf --version | head -n1
printf (GNU coreutils) 8.32
$ printf '%a\n' 1.0251998901367188e-05
0xa.c0000000000025cp-20
$ /usr/bin/printf '%a\n' 1.0251998901367188e-05
0xa.c0000000000025cp-20


> I suggest to parse the argument as a "long double" only if the "L"
> length modifier is provided, like in C.
Thanks, good idea.

I checked, and this also appears to be a POSIX conformance issue. POSIX 
  says that floating point operands "shall be evaluated as if by the 
strtod() function". This means double, not long double.

Whatever decision we make here, we should be consistent with Bash so 
I'll cc this email to bug-bash.

I propose that we change both coreutils and Bash to use 'double' rather 
than 'long double' here, unless the user specifies the L modifier (e.g., 
"printf '%La\n' ...". I've written up a patch (attached) to Bash 5.2 
alpha to do that. Assuming the Bash maintainer likes this proposal, I 
plan to implement something similar for Coreutils printf.