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 33545385AC0A for ; Thu, 18 Nov 2021 11:35:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33545385AC0A Received: from Express5800-S70 (z221123.dynamic.ppp.asahi-net.or.jp [110.4.221.123]) (authenticated) by conssluserg-01.nifty.com with ESMTP id 1AIBZbWg015030 for ; Thu, 18 Nov 2021 20:35:37 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 1AIBZbWg015030 X-Nifty-SrcIP: [110.4.221.123] Date: Thu, 18 Nov 2021 20:35:38 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: possible snprintf() regression in 3.3.2 Message-Id: <20211118203538.a049809d57731fe375801c15@nifty.ne.jp> In-Reply-To: <20211118000649.GG10332@venus.tony.develop-help.com> References: <20211117003718.GF10332@venus.tony.develop-help.com> <20211117182108.b38599f5e13071bf269a0d48@nifty.ne.jp> <20211118000649.GG10332@venus.tony.develop-help.com> 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=-10.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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: Thu, 18 Nov 2021 11:35:58 -0000 On Thu, 18 Nov 2021 11:06:49 +1100 Tony Cook wrote: > On Wed, Nov 17, 2021 at 01:27:55PM +0100, Corinna Vinschen via Cygwin wrote: > > I don't have a good solution. The old ldtoa code is lacking, for > > switching newlib to gdtoa I simply don't have the time. On the newlib > > list was a short discussion starting at > > https://sourceware.org/pipermail/newlib/2021/018626.html but nothing > > came out of it yet. > > > > Patches gratefully accepted (except just reverting the above change). > > From what I can tell the problem has nothing to do with the extra > precision, but has to do with misusing ndigits for the buffer size > with a %f format string, leading to a buffer overflow. > > At entry to _ldtoa_r() ndigits is 9, but for a %f format with a large > number the number of digits is more closely related to the magnitude > of the number, not ndigits. > > With the input number (9e99) and the supplied format I'd expect 109 > characters output, but outbuf is only: > > ndigits + MAX_EXP_DIGITS + 10 = 9 + 5 + 10 = 24 > > characters in length. Then, isn't the following the right thing? diff --git a/newlib/libc/stdlib/ldtoa.c b/newlib/libc/stdlib/ldtoa.c index 7da61457b..826a1b2ed 100644 --- a/newlib/libc/stdlib/ldtoa.c +++ b/newlib/libc/stdlib/ldtoa.c @@ -2794,6 +2794,7 @@ _ldtoa_r (struct _reent *ptr, long double d, int mode, int ndigits, LDPARMS rnd; LDPARMS *ldp = &rnd; char *outstr; + char outbuf[NDEC + MAX_EXP_DIGITS + 10]; union uconv du; du.d = d; @@ -2840,8 +2841,6 @@ _ldtoa_r (struct _reent *ptr, long double d, int mode, int ndigits, if (ndigits > NDEC) ndigits = NDEC; - char outbuf[ndigits + MAX_EXP_DIGITS + 10]; - etoasc (e, outbuf, ndigits, mode, ldp); s = outbuf; if (eisinf (e) || eisnan (e)) -- Takashi Yano