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 posix mode, use strtod() and double. > > 3. In default mode, use the existing code to get the highest possible > precision, as the code has done for over 20 years.
Do users really need more precision than double in the context of bash (or Coreutils) printf? Moreover, if the argument comes from a double written in decimal (as often done), using more precision will actually show garbage that was not present initially. This was how I found this issue with Coreutils printf (as I expected parsing as a double, this was very disturbing): cventin% /usr/bin/printf "%a\n" $((12196067*2**(-22))) 0xb.a18e300000000d1p-2 Note also that the "long double" precision depends on the architecture, so that this may confuse users who work with different architectures. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)