GNU bug report logs - #54785
for floating point, printf should use double like in C instead of long double

Previous Next

Full log

View this message in rfc822 format

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Chet Ramey <chet.ramey <at> case.edu>
Cc: eggert <at> cs.ucla.edu, 54785 <at> debbugs.gnu.org, bug-bash <at> gnu.org
Subject: bug#54785: for floating point, printf should use double like in C instead of long double
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 <vincent <at> vinc17.net> - 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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.