Re: possible snprintf() regression in 3.3.2

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

On Wed, 24 Nov 2021 17:52:04 +0900
Takashi Yano wrote:
> 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.

I mean...

sqrt(2)*1e70 is actually not an integer, however, double has mantissa
of only 52 bit. So, (double value)*(5^70*2^70) should be an integer.

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