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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: chet.ramey <at> case.edu
Cc: vincent <at> vinc17.net, 54785 <at> debbugs.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: Fri, 29 Apr 2022 16:16:28 -0700

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?

Previous Next

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