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

Previous Next

Full log

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: chet.ramey <at> case.edu
Cc: Vincent Lefevre <vincent <at> vinc17.net>, bug-coreutils <at> gnu.org,
 bug-bash <at> gnu.org
Subject: Re: bug#54785: for floating point, printf should use double like in C
 instead of long double
Date: Mon, 25 Apr 2022 08:03:12 -0700

On 4/11/22 11:52, Chet Ramey wrote:
> On 4/9/22 3:31 PM, Paul Eggert 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.

That'll fix the POSIX compatibility bug. However, it may be better for 
Bash to just do (1) if 'L' is supplied and (2) otherwise, even if this 
is less precise than (3). Doing it this simpler way will likely be more 
useful for the small number of people who care whether 'printf' uses 
'double' or 'long double' internally (and nobody else will care).

Doing it this way is what BSD sh does, and it's good to be compatible 
with BSD sh. Similarly for dash and for other shells.

It's also what other GNU programs do. For example, on x86-64:

  $ awk 'BEGIN {printf "%.100g\n", 0.1}'
  0.1000000000000000055511151231257827021181583404541015625
  $ emacs -batch -eval '(message "%.100g" 0.1)'
  0.1000000000000000055511151231257827021181583404541015625
  $ printf "%.100g\n" 0.1
  0.1000000000000000000013552527156068805425093160010874271392822265625

printf is the outlier here, and although its answer is closer to the 
mathematical value, that's not as useful as being closer to what most 
other apps do.

Perhaps it was OK for sh printf to use long double 20 years ago. I even 
had a hand in implementing that.[1] But nowadays it feels like a 
misfire. The overwhelming majority of apps that have developed over the 
past 20 years that use newer languages like JavaScript and Java, do not 
support 'long double'; when interoperating with these apps, using 'long 
double' in Bash printf likely causes more trouble than it cures.

[1]: 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=830de2708207b7e48464e4778b55e582bac49832

Previous Next

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