From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-01.nifty.com (conssluserg-01.nifty.com [210.131.2.80]) by sourceware.org (Postfix) with ESMTPS id 6442D385840E for ; Wed, 24 Nov 2021 09:15:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6442D385840E Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-01.nifty.com with ESMTP id 1AO9EuFi023243 for ; Wed, 24 Nov 2021 18:14:56 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 1AO9EuFi023243 X-Nifty-SrcIP: [110.4.221.123] Date: Wed, 24 Nov 2021 18:14:56 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: possible snprintf() regression in 3.3.2 Message-Id: <20211124181456.d4bfca4c5ba33dfe4e701fa4@nifty.ne.jp> In-Reply-To: <20211124175204.ff0751fd1536dde626826dd5@nifty.ne.jp> References: <20211118203538.a049809d57731fe375801c15@nifty.ne.jp> <7545bb24-43de-cd7d-0764-55c85f1af957@gmx.com> <20211121001613.GH10332@venus.tony.develop-help.com> <20211122232302.GI10332@venus.tony.develop-help.com> <20211123173409.0db4d5ccd94501ce1b8f69ea@nifty.ne.jp> <20211124124055.a90e254858b66d42aca6ecef@nifty.ne.jp> <20211124175204.ff0751fd1536dde626826dd5@nifty.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_LOTSOFHASH, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 09:15:25 -0000 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