Subject: bug#54785: for floating point, printf should use double like in C instead of long double

From: Vincent Lefevre <[email-masked]>
Date: Tue, 12 Apr 2022 02:27:37 +0200

On 2022-04-11 14:52:50 -0400, Chet Ramey wrote:
> It sounds like there are three cases.
> 
> 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow
>    length modifiers for the printf utility), use long double. This would
>    work in both default and posix modes.
> 
> 2. In posix mode, use strtod() and double.
> 
> 3. In default mode, use the existing code to get the highest possible
>    precision, as the code has done for over 20 years.

Do users really need more precision than double in the context of
bash (or Coreutils) printf?

Moreover, if the argument comes from a double written in decimal
(as often done), using more precision will actually show garbage
that was not present initially. This was how I found this issue
with Coreutils printf (as I expected parsing as a double, this
was very disturbing):

cventin% /usr/bin/printf "%a\n" $((12196067*2**(-22)))
0xb.a18e300000000d1p-2

Note also that the "long double" precision depends on the architecture,
so that this may confuse users who work with different architectures.

-- 
Vincent Lefèvre <[email-masked]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)