[PATCH 2/2] ctype: use less short names in public header
Richard Earnshaw
Richard.Earnshaw@foss.arm.com
Wed Nov 24 10:58:57 GMT 2021
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
>
More information about the Newlib
mailing list