Re: [PATCH 2/2] ctype: use less short names in public header

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 30/11/2021 17:15, Jonathan Wakely wrote:
> On Tue, 30 Nov 2021 at 17:12, Jonathan Wakely <jwakely@redhat.com> wrote:
>>
>> On Tue, 30 Nov 2021 at 15:14, Corinna Vinschen <vinschen@redhat.com> 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.