From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) by sourceware.org (Postfix) with ESMTPS id 2B76C395BC03 for ; Fri, 12 Jun 2020 22:50:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2B76C395BC03 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=raven.inka.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jw@raven.inka.de Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1jjsV5-0011GT-TK; Sat, 13 Jun 2020 00:50:15 +0200 Received: by raven.inka.de (Postfix, from userid 1000) id 55933600B6; Sat, 13 Jun 2020 00:50:13 +0200 (CEST) Date: Sat, 13 Jun 2020 00:50:13 +0200 From: Josef Wolf To: newlib@sourceware.org Subject: Re: undefined references since newlib-3.2.0 Message-ID: <20200612225013.GE15174@raven.inka.de> Mail-Followup-To: Josef Wolf , newlib@sourceware.org References: <20200612082111.GD15174@raven.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200612082111.GD15174@raven.inka.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-3489.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_NONE, 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: Fri, 12 Jun 2020 22:50:20 -0000 On Fri, Jun 12, 2020 at 10:21:11AM +0200, Josef Wolf wrote: > To be honest, I completely fail to understand how this commit > https://sourceware.org/git?p=newlib-cygwin.git;a=commit;h=f88aece242178ff0c187d56e34a79645fbc44a23 > can possibly cause those link failures. After all, > f88aece242178ff0c187d56e34a79645fbc44a23 shows no traces of abort/exit/kill/getpid. This patch replaces Balloc() by eBalloc() which calls __assert_func() on failure which in turn calls exit() and/or abort() Is this really a sane thing to do? After all, assertions should be used to detect logically impossible situations but not as a general replacement for error handling. Shouldn't those library functions simply report the error by returning NULL to the caller and let the application handle the situation? -- Josef Wolf jw@raven.inka.de