From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id CCB83385BF86 for ; Tue, 30 Nov 2021 17:52:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CCB83385BF86 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9744A106F; Tue, 30 Nov 2021 09:52:30 -0800 (PST) Received: from [10.57.0.71] (unknown [10.57.0.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E69B43F694; Tue, 30 Nov 2021 09:52:29 -0800 (PST) Subject: Re: [PATCH 2/2] ctype: use less short names in public header To: Jonathan Wakely , newlib@sourceware.org, Mike Frysinger References: <20211109012447.30698-1-vapier@gentoo.org> <20211109012459.30826-1-vapier@gentoo.org> <43a8b21c-ac4e-fd33-d7ad-ae7738329d16@foss.arm.com> From: Richard Earnshaw Message-ID: <29a9adf9-8251-d32b-6340-ea1d57ff4d9d@foss.arm.com> Date: Tue, 30 Nov 2021 17:52:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3492.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, 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: 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: Tue, 30 Nov 2021 17:52:32 -0000 On 30/11/2021 17:15, Jonathan Wakely wrote: > On Tue, 30 Nov 2021 at 17:12, Jonathan Wakely wrote: >> >> On Tue, 30 Nov 2021 at 15:14, Corinna Vinschen wrote: >>> >>> On Nov 30 12:01, Jonathan Wakely wrote: >>>> On 23/11/21 23:15 -0500, Mike Frysinger wrote: >>>>> On 23 Nov 2021 15:09, Richard Earnshaw wrote: >>>>>> This is wrong and breaks all old versions of C++. >>>>> >>>>> this is a bit vague. it would help if you provided details as to what broke. >>>>> i doubt this broke all old versions of C++ everywhere. >>>>> >>>>> i'm guessing you're referring to the GNU C++ (libstdc++) library specifically >>>>> and its hardcoding of newlib's internal ctype define names. >>>>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/config/os/newlib/ctype_base.h;hb=releases/gcc-11.2.0 >>>> >>>> Yes, you were CC'd on the GCC bug slightly before Richard sent his >>>> email to this list: >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305#c16 >>>> >>>>> if you're talking about something else, please state so clearly. >>>>> >>>>>> The GNU sim code should not be using reserved names (those starting _) >>>>>> in normal source code. Such names are reserved to the implementation. >>>>> >>>>> that's not really a good reason to go pooping all over the namespace. >>>>> >>>>> we can maintain backwards compat here for C++ code fairly easily: >>>> >>>> Yes, or only do that for GCC < 12, as I suggested in >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305#c19 >>>> >>>> #if defined(__GNUC__) && defined(__cplusplus) >>>> # if __GNUC__ < 12 >>>> >>>> The libstdc++ code on trunk uses the new _ISupper names. >>>> >>>> I have no opinion on how long you should keep such backwards >>>> compatibility around. Whatever time limit you set, at some point it >>>> will make a new newlib release unusable with past G++ versions. >>> >>> Is there a good reason to revert these patches in newlib? I see the >>> problem but I'm unclear on how problematic the change is in real life. >> >> You cannot use newlib from Git to build any released version of GCC. >> >> Is building newlib from Git only supported when using GCC trunk, or is > > Oops, I mean building *against* newlib from Git, not building newlib > itself. You can still build newlib itself, because it doesn't use C++. > But you can't build a GCC 11.2.0 compiler that uses the latest newlib > from Git as its libc. > >> it supposed to build with e.g. GCC 11.2.0 from July this year? If yes, >> then newlib needs changes (whether reverting the change entirely, or >> just making another change to restore the old names in addition to the >> new ones). > My concern is that the proposed workaround may break other (probably buggy) apps that have been relying on the old BSD internal API for 30 odd years. The proposed workaround only solves the issue for G++. R.