printf can't handle the '+' char in front of an integer

[Bernhard Reutner-Fischer]

On Wed, 31 Oct 2018 at 00:36, Denys Vlasenko <vda.linux at googlemail.com> wrote:
>
> On Fri, Oct 19, 2018 at 3:43 PM Bernhard Reutner-Fischer
> <rep.dot.nop at gmail.com> wrote:
> > On Fri, 19 Oct 2018 at 15:30, Bernhard Reutner-Fischer
> > <rep.dot.nop at gmail.com> wrote:
> > > On Fri, 19 Oct 2018 at 11:03, Cristian Ionescu-Idbohrn
> > > <cristian.ionescu-idbohrn at 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.