bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#54785: for floating point, printf should use double like in C in


From: Paul Eggert
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]