X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 83D0F3858C2C
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=develop-help.com
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=develop-help.com
Date:	Thu, 18 Nov 2021 11:06:49 +1100
From:	Tony Cook <tony AT develop-help DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: possible snprintf() regression in 3.3.2
Message-ID:	<20211118000649.GG10332@venus.tony.develop-help.com>
References:	<20211117003718 DOT GF10332 AT venus DOT tony DOT develop-help DOT com>
	<20211117182108 DOT b38599f5e13071bf269a0d48 AT nifty DOT ne DOT jp>
	<YZT1S8wDnaBuYf5u AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<YZT1S8wDnaBuYf5u@calimero.vinschen.de>
User-Agent:	Mutt/1.10.1 (2018-07-13)
X-Spam-Status:	No, score=0.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, KHOP_HELO_FCRDNS, SPF_HELO_NONE,
	SPF_NONE, TXREP autolearn=no 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 AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Wed, Nov 17, 2021 at 01:27:55PM +0100, Corinna Vinschen via Cygwin wrote:
> On Nov 17 18:21, Takashi Yano via Cygwin wrote:
> > On Wed, 17 Nov 2021 11:37:18 +1100
> > Tony Cook wrote:
> > > This came up from regression testing perl.
> > > 
> > > Regression testing of perl @4a1b9dd524007193213d3919d6a331109608b90c
> > > used (from uname):
> > > [...]
> > I found the caused by the commit:
> > commit 4d90e5335914551862831de3e02f6c102b78435b
> > Author: Corinna Vinschen <corinna AT vinschen DOT de>
> > Date:   Thu Nov 4 11:30:44 2021 +0100
> > 
> >     ldtoa: fix dropping too many digits from output
> > 
> >     ldtoa cuts the number of digits it returns based on a computation of
> >     number of supported bits (144) divide by log10(2).  Not only is the
> >     integer approximation of log10(2) ~= 8/27 missing a digit here, it
> >     also fails to take really small double and long double values into
> >     account.
> > 
> >     Allow for the full potential precision of long double values.  At the
> >     same time, change the local string array allocation to request only as
> >     much bytes as necessary to support the caller-requested number of
> >     digits, to keep the stack size low on small targets.
> > 
> >     In the long run a better fix would be to switch to gdtoa, as the BSD
> >     variants, as well as Mingw64 do.
> > 
> >     Signed-off-by: Corinna Vinschen <corinna AT vinschen DOT de>
> > 
> > Reverting this commit solves the problem.
> > 
> > Corinna, could you please have a look?
> 
> 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.

Tony

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -