The printf command assumes that floating-point arguments are long double values, which can yield surprising results, while most of the time the double type is assumed by applications (for instance, this is the case of XPath).
For instance: $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))' 0xa.c0000000000025cp-20 instead of 0xa.cp-20 (Note that ksh uses long double internally, but does not ensure the round trip back to long double, so that this is incorrect anyway; see https://unix.stackexchange.com/questions/422122/why-does-0-1-expand-to-0-10000000000000001-in-zsh by Stephane Chazelas.) I suppose that the issue is at the parsing level (after parsing the value as a double, i.e. rounding to a double, the resulting binary value can internally be stored either in a double or a long double without changing its value). I suggest to parse the argument as a "long double" only if the "L" length modifier is provided, like in C. -- Vincent Lefèvre <[email protected]> - 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)
