From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.fibranet.cat (www.fibranet.cat [88.99.13.26]) by sourceware.org (Postfix) with ESMTPS id B5BFE3858C74 for ; Sun, 20 Mar 2022 13:58:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5BFE3858C74 Received: from [192.168.1.2] (225.red-83-40-52.dynamicip.rima-tde.net [83.40.52.225]) (authenticated bits=0) by mail.fibranet.cat (8.15.2/8.15.2) with ESMTPSA id 22KDvwNf385965 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 20 Mar 2022 14:58:02 +0100 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.fibranet.cat 22KDvwNf385965 Message-ID: <66881efa-9121-0178-f804-cad530c5caa5@fibranet.cat> Date: Sun, 20 Mar 2022 14:57:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2] newlib: fix build with <20220315032550.16502-1-vapier@gentoo.org> <2c68b0f8-03ad-d93d-dd35-002a66576ff8@foss.arm.com> <16551142-64aa-fdda-8f9e-7656c6b9390f@yahoo.de> From: Jordi Sanfeliu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.fibranet.cat [88.99.13.26]); Sun, 20 Mar 2022 14:58:02 +0100 (CET) X-FibraNet-MailScanner-Information: FibraNet E-Mail Virus Protection Service X-FibraNet-MailScanner-ID: 22KDvwNf385965 X-FibraNet-MailScanner: Found to be clean X-FibraNet-MailScanner-SpamCheck: X-FibraNet-MailScanner-From: jordi@fibranet.cat X-FibraNet-MailScanner-Watermark: 1648389483.65195@Xuj1hVeCDI4sPqWgPigyBA X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: 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: Sun, 20 Mar 2022 13:58:09 -0000 For what it’s worth, I'm using GCC 4.x in my humble hobby OS (fiwix.org) focused on old i386 machines. So for me, will be fine to continue be able to build Newlib with GCC 4.x. Also, I noticed that GCC 4.x needs less memory footprint than GCC 5.x, so it makes it more appreciated in old machines. Thanks. On 3/20/22 02:21, Mike Frysinger wrote: > On 17 Mar 2022 10:49, Corinna Vinschen wrote: >> On Mar 16 22:41, Mike Frysinger wrote: >>> On 16 Mar 2022 10:17, R. Diez wrote: >>>>>> Therefore, compiling your code with GCC < 5 will silently break your application. >>>>>> After all, the only reason to use __builtin_mul_overflow() is >>>>>> that you need to check for overflow, is it? >>>>> >>>>> practically speaking, i don't think this is a big deal. newlib gained these >>>>> checks only "recently" (<2 years ago). newlib has been around for much much >>>>> longer, and the world didn't notice. >>>> >>>> Such general justifications wouldn't pass quality assurance (if we had one). >>> >>> in your opinion. software is not perfect, it's trade-offs. >>> >>>>> yes, if an app starts trying to allocate >>>>> huge amounts of memory such that it triggers 32-bit overflows when calculating, >>>>> the new size, it will probably internally allocate fewer bytes than requested, >>>>> and things will get corrupted. but like, don't do that :p. such applications >>>>> probably will have other problems already. >>>> >>>> You are suggesting that this only affects memory allocation, but the patch is for libc/include/sys/cdefs.h , so those mine traps will be available for everybody. >>>> >>>> People will tend to assume that anything in Newlib is correct, and code has a way to get copied around and re-used. >>>> >>>> There are many ways to mitigate the risk: >>>> >>>> - Require GCC 5. >>>> - Provide a proper implementation of __builtin_mul_overflow(). >>>> - Patch all users of __builtin_mul_overflow() within Newlib, so that they do not use it if the compiler does not provide it. >>>> - Issue a compilation warning for GCC < 5 that the "stub" __builtin_mul_overflow() is broken. >>>> Note that this is not actually a "stub" implementation in the common sense. >>>> - Add an "assert( false ) // fix me" inside the implementation. >>>> - Add a comment stating that the "stub" implementation is not actually correct. >>> >>> any option that prevents correct execution with gcc-4 is not an improvement. >>> if you care this much, feel free to contribute a patch. or use gcc-5+ and >>> not worry about it. >>> -mike >> >> Does anybody actually care for building with gcc < 5? If not, we >> should just make gcc 5 a prerequisite. > > i'm using gcc 4.9 for one of my targets which is why i noticed :). > -mike -- Jordi Sanfeliu FIBRANET Network Services Provider https://www.fibranet.cat