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

[Vincent Lefevre]

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 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.

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). Then this number can be stored in a long double
since any double is representable exactly as a long double.

> 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?

Concerning the compatibility, the question is: with what?
  * If the goal is to communicate with other tools (e.g. zsh,
XPath-based, but also programs that output values in decimal
from double, which is the most common type used in practice),
then double should be used.
  * If the goal is to communicate with other machines, then double
is again preferable, since the long double type depends on the
platform (x86, powerpc and aarch64 using 3 different formats).
  * Concerning just a bash script running on some machine:
  - If printf (without a length modifier) switches to double,
the behavior will change.
  - Note that the behavior of the script on different platforms
will be different if long double is used, but will be the
same if double is used.

Note that since bash doesn't support FP arithmetic in its arithmetic
expressions, it is very probable that FP values provided to printf
come from other tools (first point above), thus are probably in
double precision.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: bash does not run exit traps if the last command is a kill builtin that kills bash (`kill "$$"')

[Chet Ramey]

On 4/29/22 12:58 PM, Emanuele Torre wrote:


Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:
 Bash does not run `EXIT' traps if the last command is the kill
builtin kills that kills the shell.


Thanks for the report. This only affects -c command execution with the
fatal signal received during or after the last command. We need to check
for terminating signals before starting the shell exit process.

--
``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

[Paul Eggert]

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.