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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 54785 <at> debbugs.gnu.org, bug-bash <at> gnu.org, chet.ramey <at> case.edu
Subject: Re: bug#54785: for floating point, printf should use double like in C
 instead of long double
Date: Sat, 30 Apr 2022 09:58:47 -0700

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 POSIX does not require the C type 'double' and the C function 
strtod to be implemented via IEEE-754 64-bit floating point. POSIX 
allows 'double' and 'strtod' to be implemented via x86-64 
extended-precision (80-bit) floating point, or by any other 
floating-point type that satisfies some (weak) properties. I see no 
requirement that the shell must be implemented as if by the standard c99 
command with the default options.

The POSIX requirements on the implementation of 'double' and 'strtod' 
are so lax that Bash 'printf' could even use IEEE-754 32-bit floating 
point, if it wanted to. One could build Bash with 'gcc -mlong-double=32 
-mdouble=32' assuming these options work, and the result would conform 
to POSIX. (Not that I'm suggesting this!)


> Concerning the compatibility, the question is: with what?

I agree that it'd be a net win for Bash to use plain 'double' here; your 
discussion of the various compatibility plusses of doing that is 
compelling to me.

Previous Next

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