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

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
>>
>