From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id 40F1C3858422 for ; Thu, 18 Nov 2021 21:08:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40F1C3858422 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.15.104] ([88.97.26.74]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MNt0M-1n3AhP1GTQ-00OCY4 for ; Thu, 18 Nov 2021 22:08:43 +0100 Message-ID: <7545bb24-43de-cd7d-0764-55c85f1af957@gmx.com> Date: Thu, 18 Nov 2021 21:08:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-GB 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> From: Sam Edge Subject: Re: possible snprintf() regression in 3.3.2 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:6W/N7BNuB4+ag38UTureyojqklLtr1EDByb6m2YuiGm+WYcSueA n80B9n9G0C1p/j8Rz4cv/r0TiheW3sWBq55/V8tXUhZCYnBjOBTuKh/G4u2fY+avxc0Sf2M fZdlTg6j7GuhB8M2YKpKiYHfgAF7SV99iqNdn/ZcqpAj0zN+I3ePu3HPCq6AzSHyUTNBqMo xofoRUhzpsflV80SEKK3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:++ZNrr0pIQY=:+5P5wkN1Ld+hyRmCWrrY/K 78haoRc+DEuD5YzZBBjkG9SNbCPNw6/lcDgqz/l0Z7KY5oXfbKzEV8cFfuR1es1RrW6j+c0wd uS+IZ8l98yuZohhwJBtMgiY8OjpXYkDODf1H33bGtmKBT008ktDTIRRUsNEIwZZAt9V7yEnYM dz47noKj49Lt8LSKzzL5STM617SBamXja7/ul2tcIId53siRAtQ2psWJ/wcdnv/ONKFV2lQ+O SpCBtYwV/Ja27CIw2a1/K5hbBkjFkLQAksmUGOX1ByWgQ9Fk0tySmudK3Vw4VDtMGwplrDHvo v0HPsdhltOmDtBiPRD/DpLbai9ozIAow+JxfO2lpZrBftc5sBNmnApBt0+bxKXn0KZJ/IU8dK BYReCYrUPKwSKsv8MwIXmpEQNDMQD6hDOLCu1szin8T4U+FQuraS2B8JnGV3wzZbTQWc2d1sE AaqG09cYJfdj2jdKcFvodwF2rJ85hwNnDSfeK8EwcSw+8vXw7Dcxyq6gawcpsNyoMB1/B2ZSY 1o4FKak1VwpkFbL4hmcqW+iY6KSYryXJ8kUMRg4A4VYh/bnKhOD03jOryijl+8GbrIgSXz2q8 xGGU01jVKW/SrkTBCFe6l2osPES98eOZs5hmZr+2QAcggSPwO4GWAkz7Beiai3QOfHCuLCm00 JvjiGEMkvZiDyvEKzneHdcpSsPlNSroXtGezbGnpcc8kbt9ngq4rWi4sgyC1FGLCFNy/0Nzby +GlAfacTq4RbU/WDdTJMt70lXB+1ZXHlm+Bga8gtUEuYI6i3DmrOXIz2Gng9fBEzvG9c2dInl PEQq3/jmWNKjcu09Rj2Ce7vyIL8YljTkCjXBckS9H/D5Vns0+7AiofWxDh9/sO/LO57T1hY+T l+lAqW2DcpH/8WxO92L9Wo+/Q6cJbS0v2iUr191EcVIYRtp5obixq0TXHuO5/N+H3+DAuzASW iIlmtNmzLunolSu1BR3trGMy6KcqiBY7xqsiS40UQmdUGfyoyhN9IZvdNAKXP0oTx2QhyxZ39 uPO4oQdUK1B/ptE6t881aWsnkb5EifCp2ub5dayBmWngH9pfHzZLXXfmdDrjUmQujW7Y2sA1w RFV765Z2MhKcwU= X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, 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 21:08:49 -0000 On 18/11/2021 14:27, Corinna Vinschen via Cygwin wrote: > On Nov 18 16:11, Noel Grandin via Cygwin wrote: >> >> On 2021/11/18 3:19 pm, Corinna Vinschen via Cygwin wrote: >>> 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 1= K. >>> 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 >> printf is often performance sensitive, and using malloc there would lik= ely be significantly slower. >> >> Possibly use alloca() to allocate only the necessary amount on stack? > That's kind of what the current code does. > > But that's apparently the problem. The necessary amount is only known t= o > the current algorithm while populating outbuf already. So before my > patch, outbuf had a constant size, but it was size restricted. > >> Seems unlikely that embedded systems would be printing values that need= ed such large space anyway. > Perhaps that's a workaround: > > Use a constant buffer size, but use NDEC =3D 1023 only on Cygwin for the > time being, something like NDEC =3D 64 otherwise... > > > Corinna Hi all. I use newlib on embedded with threading libs that have predetermined fixed thread stack sizes. While we tend to have more RAM than in former times we also have multiple thread stacks. Use of alloca() or variable length automatic arrays makes me wince especially in code I might not be able to avoid calling which is often the case with XXXprintf() in third-party libraries' debug output. I'd usually rather take the performance hit from using heap instead of having to make all my stacks bigger. Just my two penn'orth. Cheers. =2D- Sam