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

On 4/30/22 05:48, Vincent Lefevre wrote: Yes, but to be clear, POSIX says: shall be evaluated as if by the strtod() function if the corresponding conversion specifier is a, A, e, E, f, F, g, or G so the number should be regarded as a double-precision number (type double). Yes, but

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

On 2022-04-29 16:16:28 -0700, Paul Eggert wrote: > On 4/29/22 13:04, Chet Ramey wrote: > > I think I'm going to stick with the behavior I proposed, fixing the POSIX > > conformance issue and preserving backwards compatibility, until I hear more > > about whether backwards compatibility is an issue

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

On 4/29/22 13:04, Chet Ramey wrote: I think I'm going to stick with the behavior I proposed, fixing the POSIX conformance issue and preserving backwards compatibility, until I hear more about whether backwards compatibility is an issue here. Come to think of it, as far as POSIX is concerned

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

On 4/25/22 3:06 PM, Paul Eggert wrote: On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks. I think I'm going to stick with

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

On Apr 27 2022, Paul Eggert wrote: > Any proposal to change 'long double' to always output leading 0 or 1 needs > to deal with the fact that this'd lengthen the output string. The real reason for not using that format is that 64 bits can be conveniently formatted without having to shift around

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

On 4/27/22 05:10, Glenn Golden wrote: Ok, I see what you mean, thanks for the explanation. I'll pose the question (or maybe file a bug report) on the glibc list. By the way I now think I see a reason for why glibc does things the way it does: it minimizes output size. 'double' has 53 bits

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

On Mon, Apr 25, 2022, at 19:33, Paul Eggert wrote: > On 4/25/22 16:50, Glenn Golden wrote: >> >> >> On Mon, Apr 25, 2022, at 13:06, Paul Eggert wrote: >>> >>> I'd like coreutils printf to stay compatible with Bash printf. Thanks. >>> >> >> Is there any interest/motivation for consistentizing

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

On 4/25/22 16:50, Glenn Golden wrote: On Mon, Apr 25, 2022, at 13:06, Paul Eggert wrote: I'd like coreutils printf to stay compatible with Bash printf. Thanks. Is there any interest/motivation for consistentizing {coreutils printf, bash printf} with glibc printf? There's a minor but

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

On Mon, Apr 25, 2022, at 13:06, Paul Eggert wrote: > > I'd like coreutils printf to stay compatible with Bash printf. Thanks. > Is there any interest/motivation for consistentizing {coreutils printf, bash printf} with glibc printf? There's a minor but notable inconsistency between them for

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

On 4/25/22 11:22, Chet Ramey wrote: Thanks for the input. You're welcome. Whenever you decide what to do about this, could you please let us know? I'd like coreutils printf to stay compatible with Bash printf. Thanks.

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

On 4/25/22 11:03 AM, Paul Eggert wrote: 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.

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

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

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

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

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

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

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

Vincent Lefevre wrote in : $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))' 0xa.c00025cp-20 instead of 0xa.cp-20 To summarize, this test case is: printf '%a\n' 1.0251998901367188e-05 and the problem is that converting 1.0251998901367188e-05 to long

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

The printf command assumes that floating-point arguments are long double values, which can yield surprising results, while most of the time the double type is assumed by applications (for instance, this is the case of XPath). For instance: $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))'