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

[Chet Ramey]

On 4/9/22 3:31 PM, Paul Eggert wrote:


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.


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.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

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

[Vincent Lefevre]

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.a18e3d1p-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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)