|
From: | Paul Eggert |
Subject: | Re: bug#54785: for floating point, printf should use double like in C instead of long double |
Date: | Fri, 29 Apr 2022 16:16:28 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
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 Bash doesn't need to change what it does. POSIX doesn't require that the shelll printf command be compiled with any particular environment. It would conform to POSIX, for example, if Bash's printf were compiled with an IBM floating point implementation rather than with an IEEE floating point implementation, so long as Bash's printf parses floating-point strings the way strtod is supposed to parse strings on an IBM mainframe. Similarly, Bash's printf can use an 80-bit floating point format if available; it will still conform to POSIX.
So this isn't a POSIX conformance issue; only a compatibility issue. Is it more important for the Bash printf to behave like most other shells and other programs, or is it more important for Bash printf to behave like it has for the last 18 years or so?
[Prev in Thread] | Current Thread | [Next in Thread] |