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

Richard Earnshaw <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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?

R.

> -mike
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.