possible snprintf() regression in 3.3.2
Takashi Yano
takashi.yano@nifty.ne.jp
Wed Nov 24 08:52:04 GMT 2021
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>
More information about the Cygwin
mailing list