delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2021/11/18/08:21:59

X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C26A385803A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
s=default; t=1637241718;
bh=qP5XGcnwS0BYbDPqdNAyQB24a4v/7qnFISsxZcAYZR4=;
h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
From;
b=BVMWqKukgUj+u0Ln1zgQ9TNhyU9aGJU/qd8eAlpGHi+Pbmd3LRw6uKrJnrWFKJ2/h
PKwAtK3PWSPPAXyqzrdkE2bKGRikVRVdl/fo6aMKzckM00QG6KzsqboXP/wfPH4puH
1ahzmhpSxGbBooGjwyHsSlX+i32G686w4+TWvInE=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82388385843A
Date: Thu, 18 Nov 2021 14:19:08 +0100
To: cygwin AT cygwin DOT com
Subject: Re: possible snprintf() regression in 3.3.2
Message-ID: <YZZSzPhbqF6cQAiu@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT 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>
<20211118000649 DOT GG10332 AT venus DOT tony DOT develop-help DOT com>
<20211118203538 DOT a049809d57731fe375801c15 AT nifty DOT ne DOT jp>
MIME-Version: 1.0
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 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>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
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 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

-- 
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019