On Wed, 31 Oct 2018 at 00:36, Denys Vlasenko <vda.li...@googlemail.com> wrote: > > On Fri, Oct 19, 2018 at 3:43 PM Bernhard Reutner-Fischer > <rep.dot....@gmail.com> wrote: > > On Fri, 19 Oct 2018 at 15:30, Bernhard Reutner-Fischer > > <rep.dot....@gmail.com> wrote: > > > On Fri, 19 Oct 2018 at 11:03, Cristian Ionescu-Idbohrn > > > <cristian.ionescu-idbo...@axis.com> wrote: > > > > Oh, an I should mention that on a 64bit box we diverge from coreutils > > printf: > > > > $ printf "%f\n" ' +18446744073709551614' > > 18446744073709551614.000000 > > $ ./busybox printf "%f\n" ' +18446744073709551614' > > 18446744073709551616.000000 > > It's far worse than that: > > $ ./busybox printf "%f\n" 18446744073709550592 18446744073709553665 > 18446744073709551616.000000 > 18446744073709551616.000000 > > 64-bit double's mantissa is only 53 bits... > > With "long double" shenanigans, I managed to "improve" this to: > > $ ./busybox printf "%f\n" 18446744073709550592 18446744073709553665 > 18446744073709550591.500000 > 18446744073709553663.500000 > > at this cost: > > function old new delta > printf_main 909 976 +67 > strtold - 19 +19 > print_direc 457 475 +18 > conv_strtod 54 61 +7 > ------------------------------------------------------------------------------ > (add/remove: 3/0 grow/shrink: 3/0 up/down: 130/0) Total: 111 bytes > > See attached. Do you think it's worth it?
I don't know. long double can be very slow (emulated) and complex to support, which might not be of concern here though. But first and foremost nobody complained yet AFAIK. Maybe keep it as is? Actively reject values too large for plain double in printf(1) for now? dunno. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
