Re: possible snprintf() regression in 3.3.2

[Takashi Yano <takashi.yano@nifty.ne.jp>]

On Wed, 24 Nov 2021 12:40:55 +0900
Takashi Yano wrote:
> 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?

The printed value is still something wrong...
sqrt(2)*1e70 should be an integer value.

sqrt(2)*1e62: OK
141421356237309519594917508377920125928940956418610020629872640.000000

sqrt(2)*1e63: NG
1414213562373095241621101250369917453154560547438491094548266395.615752

I will look into this problem.

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