From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by sourceware.org (Postfix) with ESMTPS id 82388385843A for ; Thu, 18 Nov 2021 13:19:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82388385843A Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mbkac-1mFCJH34py-00dGH3 for ; Thu, 18 Nov 2021 14:19:09 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id C1FA7A80D32; Thu, 18 Nov 2021 14:19:08 +0100 (CET) Date: Thu, 18 Nov 2021 14:19:08 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: possible snprintf() regression in 3.3.2 Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20211117003718.GF10332@venus.tony.develop-help.com> <20211117182108.b38599f5e13071bf269a0d48@nifty.ne.jp> <20211118000649.GG10332@venus.tony.develop-help.com> <20211118203538.a049809d57731fe375801c15@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211118203538.a049809d57731fe375801c15@nifty.ne.jp> X-Provags-ID: V03:K1:lFceh/bMftjl3igah0axxsRDZ+b8kWa2DfFQvQI+6Aj4BX9S9MG v8bgGXy6Mow/pGd8b39oyewzN7ED7VAtIouHGJMKSKd/VOm50o43BN2s/nns1h+BJIDbdpk ew8wSB07oC5FVot0n5hk43qKfShZAQVhcenzHP7t/iAHbrY2I1tSornqIiFnbeSGSfKLkvX /H2mrrhC+k8RG44lBCdTg== X-UI-Out-Filterresults: notjunk:1;V03:K0:i9CIkhN21f4=:gKcdT8MOAKEQg1tsXzg/U+ eruR56zoXsHdjfftL8tb2D6Yn+jvwZmM77fghcnj63HM+S9Kbk9TUeif2ouYu7a7hoxjedTYX Dy/kPH6RFBnNZVGMCrON7sexGdde8tl4j2dXDNIaf04TWctaQUcUV2piPbHGysmDBvQ99Uy5C fP1XT5OOZlcuklYz2Oi5qpynOlGYfzwg9Cbkx03xbsa6YziTewu0M4vmGeLzwGG87GZPyItXm wsaD7rbLOKT/z2H6nVSVEfm8m4OueSeJlK7pfamh99mJo3xiWjmn4lKEv5Pv50eY3tJizd398 fHoI5mksZ/LcjcofS1kGDS9IPvLUUHsYnMKHRbnZ1rdy+kCsEIC1c9Rm6GVWcW9InGrJnZiK/ lxeX7tNp3LSeXjfoGygkU4Ueuf3iKxdVtAy/gg/Ayi4S9ppyCxTMvXIPMvfuKUPxIILusyBuM iQ4NMMMIAbs4IraidIPxtl7aXbwD3jENmv1jQvnncF3THSLUzfV9sneULieblh06jViSH0f1+ YpO5GpJBxUSLVemSPMF6ZXt6e4fCcJCbMzAc3MYmSdpxDqUqfyFMHZEyg6ZPc/Kiacoe9h4Sm 30GFZyaoFd5HYM0MxBfL1vuCrQDQkW1sBX32UqxHfQTX9d1MXe9iz4Z87+fa+9b9ptc3O+YS7 uUSZKjTkZKXkJ+EFccAuQzcO1LsF9aU+VQcKoTTRBvlbx0lpjfLyfKFkqhH9AuTGF56e/dQiA zYW54r4k6ZR/07ow X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, 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 13:19:14 -0000 On Nov 18 20:35, Takashi Yano via Cygwin wrote: > 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)) Ouch. My patch raised NDEC from 43 to 1023 to allow aproximately the same number of digits as glibc. Newlib strives to support embedded targets and bare metal. Some of them are lucky if they have a stack size of 1K. The outbuf buffer is created on the stack, so I used ndigits to save stack space. While that patch fixes the reported problem, it will make users of smaller-than-Cygwin targets pretty unhappy. A workaround would be to malloc outbuf instead. Given that printf doesn't work without malloc anyway, that might be a working workaround, until somebody takes heart and provides newlib with a new ldtoa solution. Either way, this discussion should better take place on the newlib mailing list, given the embedded stakeholders on this list, ideally as reply to https://sourceware.org/pipermail/newlib/2021/018626.html If push comes to shove, we probably have to revert my patch for the time being, I guess. Thanks, Corinna