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 75FC5385802A for ; Wed, 24 Nov 2021 11:01:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 75FC5385802A 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 3D6D21FB for ; Wed, 24 Nov 2021 03:01:44 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D31873F73B; Wed, 24 Nov 2021 03:01:43 -0800 (PST) Subject: Re: [PATCH 2/2] ctype: use less short names in public header From: Richard Earnshaw To: newlib@sourceware.org References: <20211109012447.30698-1-vapier@gentoo.org> <20211109012459.30826-1-vapier@gentoo.org> <43a8b21c-ac4e-fd33-d7ad-ae7738329d16@foss.arm.com> <31b5484a-abf0-512d-c5e8-cef2d26f767a@foss.arm.com> Message-ID: <98465a23-20a3-39d3-74ae-6d2884073854@foss.arm.com> Date: Wed, 24 Nov 2021 11:01:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <31b5484a-abf0-512d-c5e8-cef2d26f767a@foss.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3493.4 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: Wed, 24 Nov 2021 11:01:45 -0000 On 24/11/2021 10:58, Richard Earnshaw wrote: > On 24/11/2021 04:15, 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. > > My apologies, I did mean to say GNU C++. >> >> 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 >> >> 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. >> > It's not 'pooping' on the namespace. Identifiers starting with _ are > all reserved, one way or another; some for the compiler, some for the > library implementation and some for future changes to the standard. > Applications have no business defining such names. > >> we can maintain backwards compat here for C++ code fairly easily: >> >> --- a/newlib/libc/include/ctype.h >> +++ b/newlib/libc/include/ctype.h >> @@ -71,6 +71,16 @@ enum >> >> /* For C++ backward-compatibility only. */ >> extern __IMPORT const char _ctype_[]; >> +#ifdef __cplusplus >> +# define _U _ISupper >> +# define _L _ISlower >> +# define _N _ISdigit >> +# define _S _ISspace >> +# define _P _ISpunct >> +# define _C _IScntrl >> +# define _X _ISxdigit >> +# define _B _ISblank >> +#endif > > >> >> #ifdef __HAVE_LOCALE_INFO__ >> const char *__locale_ctype_ptr (void); >> >> considering the numerical value is part of the ABI, not the name, libstdc++ >> could have inlined the constant values instead. i wonder how long of a version >> skew is reasonable if we wanted to transition it to the new names to match what >> glibc uses. > > > I think you'll find that the BSD libraries have been using _[ULNSPCXB] > since pretty much forever. Why do we need to be compatible with glibc? Eg: http://www.retro11.de/ouxr/43bsd/usr/src/include/ctype.h.html R. > > R. > >> -mike >> >