From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic310-57.consmr.mail.ir2.yahoo.com (sonic310-57.consmr.mail.ir2.yahoo.com [77.238.177.30]) by sourceware.org (Postfix) with ESMTPS id 5F2F13892007 for ; Thu, 30 Apr 2020 08:08:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F2F13892007 X-YMail-OSG: DE9RCzEVM1lMRHmM7YuCahP5FPATR80YOUwX1rv2xgBC4VB6W4xPC.usmPSECIs sxFZspD92TPaC5cfqvZGpEdNQ6loAxY3D7bYdbhEOuY_pWR6RHsV6EyLJlBnKHlxMKEyGzZPdguV ROp0h22Dk0q6ajIP2449_R9YVqKyLMXGvuUZLZiPWh52Gl1mQNuVwV5hnttiyNSS0tPLlsqSI3.g TYKRlK9UeElnqLxuv5sIDGJvV_l_YIVCphlwsPdVzvp3i5BUfaRHFOoDcqh6FnB_i_H7u4fWfQ20 8ue7TAC2GvfwtQVCXP7_HIo2ht_mE0208MFoXTY8JhjatRxREQQE9eRU1xlh7JgQu9LARncUJONX pG6FX0xwNB_B9qE.D62cgpLsfOMBrEbRo3C8lXSm2akr8KpctLXQTaOn9Fy0WqtCnbEFITm6Jee6 YOv.MPnMg1XbT6zmdKJhmSQCypT37BeuuVRDv9DASQFwHcP4t5S.V_30NGVUb7SAPkY87l9bBSt7 RWODC_zDqxvC2E8WFM0iw7sMpErDpIFG3dHR736JpowjmMXYP.T4JB3liXpmeEfzEkyCueZuJMXX DPoYUe9627pt0c3OeHe3tq1otez32SVB1tY4mAtso4EX6oLwF_8JMwSXA2xjUSG8Zh84uMwsmjAC iYyJf5eYai7fe6aFXJTUlX.fuO5QTTkfl08TF9xbhRkDQ0Lzmj_l3EQ2CNhBQNMuQM.mRGLEmibE WuvPDXnzLFXxMjkZDpai6xTiCQzVJl3ECJyk_qcEwxouketKDvHAOsYzZkA0pQYHZ1QnHAbosBFS s6ainzEYl1hQUMWKn6PE6UWNrDhmFuj1lo6mDXkH_68BavyTHrinCKMPSDxUgR5Qjxzm_UVAOHIM Pqe.e4wQjjbkXfZReNscIaTNp5SlHIBl_RLAJV6._UcWuPqa9pJrC_q9GNZldRi9NnBWSHPPDOY4 nC_1biNP6rji05MPZtuGnJNldF7afBUpt4ofx4f0ykrLuhtn.LS3W_.LhU2S6cAI4RHpqX7uDdPM YVsPhERvfYUDKuRE882wDW3ZUoy3ZC39_jUPSMwi_rBEZV03a3r4yIZQOwDuraQL.4e7uXQ7XU9k 5ZOQYy_PbbJlgWm7nZqjfW.hySLTIkttceMdyioggWGOppcsxzbXyu2Hig99Q1uPviaG0dGnVCQX gfWlVjdMdUwYxPi_SmzyRDt4WIwnOSRyRWvI7XLgsRq58iWcbqy.BAor5.Ge1boGCNz6KNnqTX_B om9bnkU8T_s.PMqIOLcBKalE4OFKM9_1O6rfOXCUFyWydO2.ofBf6ImA7edP42XFzv2i2cIV71oi RUrljgMk1TtEoHXvsNR3xcLkc5QysaCdbFHEG4cfbA2b4yJbPaQuSaaD7TxpJleClfkk4vAOMTF9 nT19FJ.XnP.MuqlUobocUsih28PgQVBrJ__UZxx4aE3IIW3u6yg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Thu, 30 Apr 2020 08:08:55 +0000 Received: by smtp429.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 61593b8b2683bca4e1f609a788d6c78e; Thu, 30 Apr 2020 08:08:50 +0000 (UTC) Subject: Re: _REENT_CHECK_VERIFY calls __assert_func even if NDEBUG is defined To: Jeff Johnston Cc: "newlib@sourceware.org" References: <989180140.2023825.1588003097077.ref@mail.yahoo.com> <989180140.2023825.1588003097077@mail.yahoo.com> <1918742529.2295153.1588019348307@mail.yahoo.com> <1949956947.2883373.1588075584956@mail.yahoo.com> From: "R. Diez" Message-ID: Date: Thu, 30 Apr 2020 10:08:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 08:08:58 -0000 > [...] > Regarding the _REENT_CHECK_VERIFY macro, this only affects you if you a= re using _REENT_SMALL. I have been looking around further. I have come to the conclusion that advertising configuration option "--en= able-newlib-reent-small" as "enable small reentrant struct support" is=20 actually doing a disservice to Newlib's users, especially in an embedded = environment. Those surprising calls to malloc() have a performance impact, as malloc()= can be slow. They also cause safety issues, because of the unexpected ex= tra=20 memory consumption (memory is sometimes painstakingly accounted for). Aft= er all, there has already been a CVE in this area, and memory exhaustion = at=20 this unexpected place will crash the firmware. There is a further issue: = malloc() is not safe everywhere (like inside an interrupt routine). Therefore, I believe the only right thing to do is to place a warning nex= t to that configuration option. For example, something like "warning: cau= ses=20 hidden malloc()'s on first touch" should suffice. > With that set-up, the reentrant structure is minimal to start with and > storage is allocated at the last minute, if needed.=C2=A0 If you look i= n libc/sys/reent.h > you will see that for the non _REENT_SMALL configuration, the > [...] OK, thanks for confirming this. There is no libc/sys/reent.h as far as I can tell. Confusingly, there are= 2 files with the same name in Newlib: newlib/libc/include/reent.h newlib/libc/include/sys/reent.h I guess you are referring to the second one. For convenience, it's here: https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dnewlib/lib= c/include/sys/reent.h I looked inside, and I do not understand why struct _reent has to be 1064= bytes long. There is space for __FILE structures, but my firmware is not= =20 using the STDIO routines at all. I am configuring with --disable-newlib-i= o-float, --disable-newlib-iconv , etc., so my guess is that many of the=20 members inside struct _reent will never be used and could be optimised aw= ay with #if statements. You could even configure the rand() data away if you can live with the we= aker rand_r() variant. There are some comments there about trying to maintain binary compatibili= ty. Is this something that Cygwin needs? At least in an embedded environm= ent=20 there is no need for that. I thought that struct _reent is something inte= rnal to Newlib, or are there public fields meant for the library user? Note that the size of this structure is not always the same. For example,= member "_atexit" depends on "#ifndef _REENT_GLOBAL_ATEXIT". Therefore, t= his=20 structure already varies in length today. > So, you have a number of choices: >=20 > 1. don't use _REENT_SMALL and rand() won't allocate storage when used > 2. use _REENT_SMALL but call rand() at the start of your application so= it won't try to allocate memory later on > 3. use _REENT_SMALL and ensure you have enough extra storage allocated = to handle the apps needs and the minimal storage needed for the rand48 lo= gic > 4. allow the abort or null pointer access to occur and tune the applica= tion not to run into this scenario if it does happen This is an excellent summary about dealing with configuration option "--e= nable-newlib-reent-small". Is there any chance it could make it to the Ne= wlib=20 documentation? Best regards, rdiez