On Tue, 23 Nov 2021 10:48:21 +0100
Corinna Vinschen wrote:
> On Nov 23 17:34, Takashi Yano via Cygwin wrote:
> > However, in reality, for example in the case:
> > snprintf(buf, sizeof(buf), "%.3f", 1234567890123456.789);
> > 'ndigits' is only 3 even though total digits will be 20.
> > 
> > So, Tony thinks current code does not correct.
> > 
> > However, I think something is wrong with interpretation
> > of 'ndigits' in dltoa.c.
> > 
> > printf("%.3f\n", sqrt(2)*1e70);
> > printf("%.50f\n", sqrt(2)*1e70);
> > 
> > outputs
> > 
> > 14142135623730951759073108307330633613786387000000000000000000000000000.000
> > 14142135623730951759073108307330633613786386978891021459448717416650727.13402790000888758223149296720949629080194006476078
> > 
> > Is this as intended?
> 
> On Linux I see
> 
> 14142135623730951759073108307330633613786387161811679011529922516615168.000
> 14142135623730951759073108307330633613786387161811679011529922516615168.00000000000000000000000000000000000000000000000000
> 
> The newlib output for .3f probably suffers from the fact that ldtoa
> chooses the small buffer, which restricts the number of digits to 43 or
> 44.  But keep in mind that ldtoa *always* restricted the output to 42,
> so you never got a more precise output anyway.  Every digit beyond digit
> 42 is only printed due to the bigger buffer sizes.
> 
> So, what newlib and, in extension, Cygwin really needs at this point are
> patches to the existing ldtoa or a change to gdtoa or equivalent.
> 
> https://cygwin.com/acronyms/#SHTDI
> https://cygwin.com/acronyms/#PTC

The attached patch is the one which I think correct so far.

With this patch:

14142135623730951759073108307330633613786386978891021459448717416650727.134
14142135623730951759073108307330633613786386978891021459448717416650727.13402790000888758223149296720949629080194006476078

Isn't this better than current behaviour?


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>